Microservice frameworks

When dealing with frameworks, we have to think that because of the technological diversity of our frameworks, we will have at least three frameworks instead of one to keep our ecosystem.

Of course, we could have kept all microservices in the same stack. However, searching for the best overall performance for each domain, we opted for a more plural stack.

Obviously, at first, the impression is that the complexity will be higher than expected. But this type of complexity is matched by the performance most suitable for each case.

Basically, we chose three different programming languages to use on our news portal. Python, Go, and C# are those languages. It is time to think about which frameworks we will use for each of these languages, thus taking another step in shaping our development stack for each microservice.

Python

In the world of Python, there is a multitude of interesting frameworks; Bottle, Pyramid, Flask, Sanic, JaPronto, Tornado, and Twisted are some examples. The most famous that has more support from the community is Django.

Django is the same framework that was used to build our news portal in the monolithic version. It is a very good tool for full-stack applications and has, the main characteristic, and the simplicity to mount this type of software.

However, for microservices, I do not think it's the best framework for this purpose. Firstly, because the exposure of APIs is not native to Django. The ability to create an API with Django comes from a Django app called Django Framework Rest. In order to maintain the standard structure of the Django framework, the design of a simple API was a bit compromised. Django provides the developer with the entire development stack, which is not always what you want when developing microservices. A more simplistic and more flexible framework for compositions can be interesting.

In the Python ecosystem, there are other frameworks that work very well when it comes to APIs. Flask is a good example. An API, Hello world, is made in a very simple way.

Installing Flask with the command:

$ pip install flask

Writing the endpoint is very simple:

# file: app.py# import de dependenciesfrom flask import Flask, jsonify

Instantiating the framework:

app = Flask(__name__)

Declaring the route:

@app.route('/')def hello():    #Prepare the json to return    return jsonify({'hello': 'world'})

Executing the main app:

if __name__ == '__main__':    app.run()

The preceding code is enough to return the message hello world in JSON format.

Other frameworks were inspired by Flask and worship the same simplicity and very similar syntax. A good example is Sanic.

Sanic can be installed with the command:

    $ pip install sanic 

The syntax is almost identical to Flask, as can be seen in the following code:

# file: app.py

Importing the dependencies:

from sanic import Sanicfrom sanic.response import json

Instantiating the framework:

app = Sanic()

Declaring the route:

@app.route("/")async def test(request):    #Prepare the json to return    return json({"hello": "world"})

Executing the main app:

if __name__ == "__main__":    app.run(host="0.0.0.0", port=8000)

The big difference between Flask and Sanic is the performance. The performance of Sanic is much higher than Flask due to use of newer features in Python and the possibility of the exchange of the Sanic framework. However, Sanic is still not as mature and experienced in the market as Flask.

Another plus point for Flask is the integration with other tools like Swagger. Using the two together, our APIs would be not only written but also documented appropriately.

For microservices using Python as a programming language, performance is not the most important requirement, but practicality. Use this framework as Flask microservices.

Go

This is a totally different Python case. While most Python frameworks help with performance and try to provide the best possible environment for development, Go is not the same. Usually, frameworks with many features end up compromising the performance of the language.

Logs

When it comes to logs, they are virtually unanimous. You may refer to the logrus document  (https://github.com/Sirupsen/logrus). It is a very mature and flexible logging library for Go, having hooks for different tools, ranging from the syslog to the InfluxDB for example.

The logrus has main features, that is, speed up on record logs and practicality of implementation.

Handlers

Creating routes to APIs in Go is very simple, but using native handlers' options can generate certain complexities, especially regarding the validations. The native muxer does not have a lot of flexibility, so the best option is to seek more productive tool handlers.

Go has a multitude of options for handlers, and perhaps the most explored library model because of the characteristic of writing the low-level language.

When it comes to performance for routers in Go, at the time of release of this book, there is nothing more performative than fasthttp: (https://github.com/valyala/fasthttp).This is a library written using Go that provides low-level language. Fasthttp metrics are outstanding.

Here are the numbers running tests locally to provision static files:

Running 10s test @ http://localhost:8080  4 threads and 16 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   447.99us    1.59ms  27.20ms   94.79%    Req/Sec    37.13k     3.99k   47.86k    76.00%  1478457 requests in 10.02s, 1.03GB readRequests/sec: 147597.06Transfer/sec:    105.15MB

As it can be seen, the number of requests per second exceeds 140,000. However, writing the routes using fasthttp can be as complex as with the native library. Due to this problem, there are some frameworks that do interface for fasthttp. One of these interfaces is the fasthttprouter (https://github.com/buaazp/fasthttprouter), which ultimately creates a number of development facilities without overly compromising the good performance of fasthttp.

Writing routes with extreme performance is very seductive, but we need a balance between performance and stability; here we have a point needing attention. Fasthttp, as well as all its aid interfaces, modifies the native standard of the handler Go to implement the context itself. If there really is a big performance problem, using fasthttp may be something to think about. I do not think this is our case. Therefore, it is recommended to use something that has more compatibility with the standard Go interface.

The most famous option is gorilla/mux (https://github.com/gorilla/mux). Without a doubt, it is one of the most mature and experienced libraries for Go.

Middleware

For the composition of our middleware, use Negroni (https://github.com/urfave/negroni). In addition to being a very mature tool, it has complete compatibility with the Mux Gorilla and the native API Go.

Tests

For unit testing, use the testify: (https://github.com/stretchr/testify). It is a simple library which accrues in both assertions and mocks. For functional testing, use the default Go library.

Package manager

If the Go ecosystem has a weak point, it is this. Go dependency management has always been something that requires a lot of attention.

If you do not know, the official repository of the Go dependencies is Git. Exactly, all Git, no matter if it's GitHub, Bitbucket, or any other. The problem is that when downloading a dependency using the Go command (go get ...), the version that will come to the application is always the one in the master repository. So there is no strict control of additions.

A package manager will use godep (https://github.com/tools/godep). This is a simple tool, which controls the versions used in the project guarding a JSON file with the repository URL and hash Git history.

Golang ORMs

A feature which is adopted by the Gophers, the name was given to developers using Go, is not using ORMs. Often the preference is to use only the communication driver in the database.

Often Gophers dispense the using of an ORM to adopt just a tool that helps to make more practical information from the database in a Go struct. A tool of this type of relational database is SQLX (https://github.com/jmoiron/sqlx).

SQLX does not work like ORM; it is only library to create a more friendly interface for native Go packages to communicate with the database/SQL.

If the chosen database application is to be NoSQL, it will hardly be adopting any data interpretation tools, as the most practical method is to use only the available driver.