WeGO

A Micro Services Framework

Introduction

WeGO is a flexible (yet opinionated) framework that is suitable for rapid development of micro services. The GOLANG architect has a few important responsibilities:

1. Make a choice from various frameworks that exist in the GO LANG ecosystem.
2. Standardize them and

GOLANG has a nice ecosystem of packages that solves specific problems very well. When it comes to writing Micro services, the developer has the onus of stitching them all together to make them perform the work. This presents a few challenges:

1. The author has to decide which frameworks to use
2. After deciding on the framework, the developer has to make decisions on the best practices around using the chosen framework.

WeGO does both these things for you.

The chief benefit of WEGO is that it comes integrated with different frameworks that have been standardized such as:

• gorilla MUX (for HTTP)
• Uber zap (for logging)
• New Relic (for monitoring)
• GoDog (for BDD)
• Viper (for configuration management)
• Nick Snyder’s go-i18n

Besides integration with frameworks, WeGO accomplishes the following:

• Provide a standardized folder structure for development.
• Allows developers to focus on business logic without being bothered about how services are exposed via HTTP etc.
• Facilitates interface service separation
• Integrates with Make for builds. See approach to builds
• Integrates with Docker for deployment. See docker integration
• Exposes HTTP for the services. For details see the http module
• Enforces a common set of middlewares. For details see the discussion on middleware
• Facilitates rapid development using a code generator. For details see the discussion on code-gen
• Implements a state machine. See the WeGO State Machine
• Provides a consistent way of handling Errors. See Error Handling
• Provides the following functionalities as horizontal services. (a growing set) # Logging. See WeGO Logging # Auditing (not implemented yet) # Monitoring. See WeGO integration with New Relic # Configuration Management. See WeGO approach to Configuration Management

Modularized code base

WeGO is a modularized code base with a base framework and several set of plug-ins. All the plug-ins are shipped together in one GO Module. However, it is easy to dissociate them if the need so arises.

Folder Structure

WeGO is best implemented using a folder structure as follows: $ mkdir src $ cd src $ git clone github.com/agorago/wego (get the actual git repo url) $ git clone github.com/agorago/wego-gen (get the actual git repo url) $ mkdir configs

All included git projects will be under src. Reference to other WeGO projects will be relative. For example, you will create a relative path to WeGO in your module by typing the following: $ cd src/my-service $ go mod edit –alter github.com/agorago/wego=../wego

This establishes the relative path to WeGO from your service and allows changing of the WeGO code without requiring “go” to extract the latest code from gitlab.

Project Types

We would have three sets of projects that need to be developed. All these project templates are generated automatically using code-gen. These include the following:

1. A service project. This is the project that a developer uses to develop a micro service.
2. A deploy project. This gives a dev-ops person the flexibility to package multiple micro services into a single deploy-able artifact.
3. A state service project. This is a project that uses a state machine for developing services. The chief difference between this and the service project is that this project is driven by a state machine. The code structuring is around the state machine.

Development & Test Process

The Makefile generated by code-gen and which becomes part of every service accomplishes a few things to make it easier for the development and testing process. Before we launch into a discussion of these features, we need to understand the dependencies.txt file which is generated by code-gen.

dependencies.txt file

Every service will have a dependencies.txt file that contains the dependencies for the service. Dependencies are Intelligent B projects.(Dont confuse these with external open source dependencies such as go-kit, viper, mux etc.) This file is not supposed to replicate what is already contained in files go.mod. However this file is necessary to accomplish the following objectives:

• To enable developers to make changes in the dependency project and seeing these changes immediately being reflected in their code base without the need for doing a “git commit”. This is accomplished by doing a “go mod edit –alter dependency-project-url=../dependency-project-relative-path” This creates an entry in go.mod for the relative path to this folder.
• To copy the resource bundles from the dependent projects into a common area
• To copy environment settings from the dependent projects into a common area
• To copy workflow resource files to a common area
• To execute the go generate for error codes for the dependent projects.

Steps

Development involves the following steps:

1. Building - make build
2. Running unit tests - make test
3. Editing go.mod to use the relative paths rather than the gitlab URL for dependent projects. This in turn enables developers to make local changes to dependent
4. Code Generation (for generating error descriptions)- make generate-error-codes
5. Copy the configurations (under the configs folder to the CONFIG PATH. The config path is by default located at ../configs. make copy-bundles
6. Running the executable - make run

In reality, the Makefile defines the targets - generate-error-codes and copy-bundles as dependencies of the run target. Hence triggering step#6 above automatically triggers step#1, step#3, step#4 and step#5.