Doing Frontend Development with Golang, JavaScript and Docker (Part The Second)

Arthur’s web app. Now we Dockerize it!

This series:

• Part the First: Better JavaScript in Go with Vite
• Part the Second: Dockerize Your Go and Vite Setup (here)
• Part the Third: Creating Certificates and Setting up a Router

Last time, we took a Golang web app, and used Vite 3 to improve our developer experience with developing JavaScript and CSS to work with the app. You can find the app as we finished part one here on GitHub.

Since our goal is to set up a local development environment for doing front end work with Go, this time we’ll look at moving this work to Docker. Docker environments are more light weight than virtual systems, and they tend to be more reliable and reproducible than set ups directly on our laptops or office computers.

I’m going to assume you have some kind of Docker solution installed on your computer. DDEV, a wonderful docker-hosted development system used by PHP developers, has a good tutorial on your options depending upon platform. If you’re not sure what to do, that’s a good place to find practical suggestions. I’ll be using Colima, an open source solution used mostly on the Macintosh. But if your installation will support DDEV, it will work fine for this tutorial.

Adding Directories for our Docker Containers

Right now, if you check out the files for after Part 1, you’ll see something like this:

.
├── README.md
├── frontend
│   ├── favicon.svg
│   ├── index.html
│   ├── package-lock.json
│   ├── package.json
│   ├── public
│   │   └── vite.svg
│   ├── src
│   │   ├── main.ts
│   │   ├── style.css
│   │   ├── typescript.svg
│   │   └── vite-env.d.ts
│   ├── tsconfig.json
│   └── vite.config.ts
├── go.mod
├── go.sum
├── main.go
└── templates
    ├── base.layout.gotmpl
    ├── quest.page.gotmpl
    └── result.page.gotmpl

Create a “docker” directory at the same level as main.go, and create two directories inside of it:

docker/
├── goapp
└── vitevol

These will be our build directories for our Go and Vite containers. Let’s start with Vite.

Building The Vite Image

We’re going to create the following files:

vitevol/
├── .dockerignore
├── Dockerfile
├── frontend
│   └── .gitmanaged
├── start-vite-proj.sh

Dockerfile and .dockerignore are standard files for building containers. start-vite-proj.sh is a script we’ll write to start up the container; and “frontend” will be where we mount our local development files into the container. If this seems a bit confusing, hold on a bit, since we’ll do this step by step.

In .dockerignore we have:

node_modules

This is important, since the contents of node_modules/ will be different inside of Docker, which is a Linux environment. We don’t want to use our local copy, so .dockerignore makes sure we make a fresh copy.

The Dockerfile:

FROM node:18
ARG PORT=5173
RUN mkdir -p /app
WORKDIR /app
COPY . .
RUN cd /app; npm create -y vite@latest vitebin -- --template vanilla
RUN cd /app/vitebin; npm install
EXPOSE $PORT
ENV PORT ${PORT}
WORKDIR /app/frontend
CMD [ "sh", "-c", "/app/start-vite-proj.sh"]

We install Vite in order to get the vite script; we won’t use anything else from the install. We use an ARG to allow us to change the Vite port from our docker-compose.yaml file, and set the WORKDIR to “/app/frontend”. In docker-compose.yaml we will mount our local “frontend” directory at this point.

And then, we run the start-vite-proj.sh script:

#! /usr/bin/env bash
cd /app/frontend
npm install
echo "Port before default assignment: $PORT"
echo "PORT is ${PORT}"
/app/vitebin/node_modules/.bin/vite --host 0.0.0.0 --port $PORT

(Remember to make this file executable either locally, or if you’re using Windows, add a command to do that to your Dockerfile, since Windows does not have a chmod command).

Test that this builds by doing:

cd vitevol
docker build -t somename .

This should work; if not, you’ll need to debug your Dockerfile.

Building The Go App Docker Image

This is even easier to do, since we’re going to base our image off the Air utility, which watches your go files, and when they change, compiles and runs the new files. The author has been kind enough to create a docker image of it, so we get a dockerized Go environment essentially for free. The docker/goapp directory contains these files:

goproj/
├── Dockerfile
├── project
│   └── .gitmanaged

Here “project” is our mount point for our Go files, which are at the top level of our files. The Dockerfile is pretty simple:

FROM cosmtrek/air
# Set up our dev area
RUN mkdir /app
WORKDIR /app
COPY . .
EXPOSE 80
CMD [ "/go/bin/air", "-w", "/app/project" ]

As simple as this is, it’s all we need, since GitHub’s cosmtrek has done all the difficult stuff. You should test building this image as well.

Writing a docker-compose.yaml File

Now that we can build our images, it’s time to hook them up to the docker-compose utility. At the top level of our project, we create a docker-compose.yaml file. It looks like:

version: '3'
  goapp:
    container_name: goapp
    image: vitestuff/goapp
    ports:
      - 80:80
    environment:
      - air_wd=/app/project
    build:
      context: docker/goproj
    volumes:
      - consistency: cached
        source: .
        target: /app/project
        type: bind
  vite:
    container_name: vite
    image: vitestuff/vite-env
    ports:
     - 5173:5173
    build:
      context: docker/vitevol
      args:
        PORT: 5173
    volumes:
      - consistency: consistent
        source: ./frontend
        target: /app/frontend
        type: bind

This file sets up the following:

• Instructions for building the two docker images from their respective sub-directories.
• Assign the ports exposed from inside of Docker out to your host computer.
• Mount the Go files into the goapp container, and the frontend directory into the vite container.

This is almost enough for us to get things working. It is enough to test the file — syntax for docker-compose.yaml files is tricky, and making errors is easy if you don’t indent consistently. Run the following commands, and make sure that they work:

docker-compose build 
docker-compose up

Once these work, we have two things we’ll want to fix. First, if you use just the setup I’ve described so far, Vite will run, but it will ignore any changes to your files; HMR will appear to be broken. The fix here is to modify frontend/vite.config.ts as follows:

import { defineConfig } from 'vite';
export default defineConfig({
    server: {
        watch: {
            // bind volumes don't get fs events
            // so we need to poll now.
            usePolling: true,
        },
    },
    build: {
        manifest: 'manifest.json',
    },
});

The server.watch configuration will make Vite check every few seconds if files have changed; I find it takes about 10 seconds, but that is better than “ignore those files forever” :-)

Air does not have this problem, but w/o additional configuration, it will watch too many files, which can be a problem in Linux systems; file handles are a limited resource. The fix is to create a config file (.air.toml) for Air at the same level as your main.go file. Mine looks like this:

root = "."
testdata_dir = "testdata"
tmp_dir = "tmp"
[build]
  args_bin = []
  bin = "./tmp/main"
  cmd = "go build -o ./tmp/main ."
  delay = 1000
  exclude_dir = ["assets", "tmp", "vendor", "testdata", "docker", "frontend"]
  exclude_file = []
  exclude_regex = ["_test.go"]
  exclude_unchanged = false
  follow_symlink = false
  full_bin = ""
  include_dir = []
  include_ext = ["go", "tpl", "tmpl", "html", "gotmpl"]
  kill_delay = "0s"
  log = "build-errors.log"
  send_interrupt = false
  stop_on_error = true
[color]
  app = ""
  build = "yellow"
  main = "magenta"
  runner = "green"
  watcher = "cyan"
[log]
  time = false
[misc]
  clean_on_exit = false
[screen]
  clear_on_rebuild = false

The key changes here are to exclude_dir (I’ve added docker and frontend to those directories) and for include_ext, gotmpl to the list of extensions. This will make sure that Air does not get lost in your node_modules directory, and that it does notice when you change your *.gotmpl template files. Change the settings accordingly if you add more directories or use a different extension for your templates.

Once you’ve made these changes, interrupt docker-compose up and start it again. You should see Air pick up your changes, and you won’t have to wonder why Vite is ignoring your changes, as happened to me :-)

You now have the following setup, and you should be able to browse to http://localhost and see a working copy of the app:

Network diagram for the end of the second article.

This should work almost exactly like running the programs on your local system.

At this point, your install should look a lot like this section of the repo. That should be enough for this second part of the series. We’ll finish this up with installing SSL in the third and last article.

Rob Thorne is a full-stack developer who’s doing more and more devops these days. He’s available for hire. You can find Rob on Twitter as @torenware.