Using ‘Go Generate’ To Deploy Multi-Process Apps
Tags: engineering, go, programming, tutorial
Published: 2020-04-22 13:29:20

---
title: Using ‘Go Generate’ To Deploy Multi-Process Apps
published: true
date: 2020-04-22 13:27:33 UTC
tags: Engineering,Golang,Programming,Tutorial
canonical_url: https://qvault.io/2020/04/22/using-go-generate-to-deploy-multi-process-apps/
---

![](https://qvault.io/wp-content/uploads/2020/04/GE-740x520-1.jpg?x19005)<figcaption>PSP31475-00, 7HA.02 Gas Turbine, Rotor Instalation, Greenville, SC, USA, DI-3800×5700</figcaption>

In microservice architectures, it is fairly common to have a project that includes different worker types. A [Makefile](https://en.wikipedia.org/wiki/Makefile) can be used to manage the creation of multiple programs, but the Go toolchain has a great tool that can be used as well, [go generate](https://blog.golang.org/generate). Here are some examples of how we take advantage of ‘go generate’ at [Nuvi](https://nuvi.com):

- **API/Worker** – We have an API that allows clients to start/stop long-running jobs, and a worker which accesses the same database to run the jobs.
- **NLP Classifier** – We have different processes that share a majority of the same code, but have different quirks depending on if they are classifying sentiment, vulgarity, or subjectivity.

In other words, we have one git repository, but from that code, we want to generate ‘ **n** ‘ number of executables.

## Repository Structure

Our normal single-process repositories have the following structure:

- `main.go`
- `foo.go (other main package source files)`
- `bar.go`
- `internal (folder for packages intended just for this project)`
  - `database (package for database access)`
    - `database.go`

  - `rabbit (package for rabbitmq access)`
    - `rabbit.go`  

As you can see, when there is only one program (one main.go) its really easy to build and deploy. We just run:

```
go build
```

from the root of the repository.

## Structure With Multiple Programs

Now let’s say we have a project that has an API that is responsible for managing some long-running jobs. For example, we can pretend it manages RSS scraping jobs. Here is how we would build out the repository:

- `cmd`
  - `api`
    - `main.go`

  - `worker`
    - `main.go`
- `internal (folder for packages intended just for this project)`
  - `database (package for database access)`
    - `database.go`
  - `rss (package for rss scraping logic)`
    - `rss.go`
- `gen.go`

Here we have a **cmd** folder in the root, which then holds a directory for each executable. This allows us to still scope packages to the entire project, share a CI/CD pipeline, and keep code that is tightly-coupled all in one place.

## How Do We Build It?

In the above project structure, you may have noticed the gen.go file. Here is what it looks like:

```
package main

//go:generate go build ./cmd/api
//go:generate go build ./cmd/worker
```

Now we can run **go generate** from the root of our project and both executables will be built at the root.

The **generate** function is a powerful tool and can do a lot more than just build a list of executables. Nevertheless, we’ve found this to be a convenient way to keep our projects “go native”.

## Thanks For Reading

Hit me up on twitter [@wagslane](https://twitter.com/wagslane) if you have any questions or comments.

Follow me on Dev.to: [wagslane](https://dev.to/wagslane)

The post [Using ‘Go Generate’ To Deploy Multi-Process Apps](https://qvault.io/2020/04/22/using-go-generate-to-deploy-multi-process-apps/) appeared first on [Qvault](https://qvault.io).