After checking the state of the art of Go package managers, the best option seems to be:

golang/dep

We only have one external dependency (gorilla/mux) so it feels like a good time for migrating.

As an example, here it is a Go project that uses dep:
https://github.com/percona/mongodb_exporter

It would be nice to have a couple of scripts that take care of the following points:

• Install deps and start the project for development
• Build the docker image for multiple architectures. Also, integrate it with TravisCI for pushing de image to Docker Hub when a tag is present:

This project is a good example:
https://github.com/mmontes11/iot

Here it is an example:
https://github.com/mmontes11/crypto-trade

Based on our services model, we will need to define a dynamic routing for our microservices. Since model layer is not ready yet, we will need to use a mock, more info at #3 .

Asuming that we have this model:

Our dynamic routing will consist of the following forwarding rules:
GET /api/stock => GET http://stock.microservice/api
GET /api/catalog => GET http://catalog.microservice/api
GET /api/checkout => GET http://checkout.microservice/api

If the client tries to route to a non existing microservice, we should return a 404 Not found.
If the request to the microservice fails, we should return a 502 Bad Gateway.

Since our microgateway is not integrated yeat in any microservices platform it would be nice to have a couple of mock microservices for testing purposes.

Create the following endpoints for managing services:

• POST /api/service: Our actual /api/register
• GET /api/service/{servicename}: Get a service and its status
• GET /api/services: Get all services and its status

Like the cache endpoints defined in #23, they can be very useful for have a picture and managing the actual status of microgateway.

Considering this, it would be nice to rename /api/{service} endpoint to /{service}. Also, a prefix path may be configured via an env variable SERVICE_PATH_PREFIX, so the endpoint would be /{pathPrefix}/{service}

It seems that dep is deprecated in favour of go modules:
golang/dep@87f3094
https://levelup.gitconnected.com/switch-to-go-modules-from-go-dep-fcdd4aa41bd5

• When checking a service health url log at least the services transitioning from one state to another.
• When a service is registered log it.
• Check if more logs are needed.

Since the routing will be totally dynamic we will need to manage the different service endpoints that we will route to.

For dealing with persistence, we can use Redis as a key value store, where the key will be the name of the endpoint and the value the url.

For example:

For creating those Redis items we will need to add and endpoint in our micrograteway:

POST /service
{ "key": "stock", "url": "http://stock.microservice" }

Since we are using new infrastructure it would be nice to have a docker-compose.yml for setting it up for development. For production, we will use Kubernetes but we will take care of that in the future in another issue.

Health http requests and redis queries can be parallellized when checking a list of service statuses.

After checking a few open source Go projects, having a Makefile looks like a must.

Here it is an example project:
https://github.com/percona/mongodb_exporter

Every 10 seconds (configurable) the microgateway checks if the services registered are alive using the healthUrl provided by the service when it was registered. Also, we need to add a new property in redis called "status" with two possible values: HEALTHY or IDLE.

Initially the service has a HEALTHY state. Now if the healthcheck fails (HTTP response != 200) or times out the state is changed to IDLE. Request to this microservice will not be routed and we will return a HTTP 502. If the service comes up again we will revert the state change and route requests again.

Implement a 2 layer request cache:

• Server side cache: Microgateway will cache responses in redis with a given TTL
• Client side cache: Responses will be stored in client's disk with a given TTL
  For supporting this, a new field cache will be specified when registering a microservice:
  POST /api/service

{
    "type": "rest",
    "url": "http://catalog",
    "path": "catalog",
    "healthPath": "health"
    "cache": {
         "defaultTtl": 600,
         "statuses": [200, 404]
         "tags": ["catalog", "products"]
     }
}

Where:

• defaultTtl: Will be the default server side cache in seconds
• statuses: Cacheable status codes
• tags: Will be used for cache invalidation

A microservice will be able to override its values by providing the following headers in its responses:

• Cache-Control: max-age=60: Set client TTL to 60 seconds for the corresponding request
• Cache-Control: s-maxage=120,: Set server TTL to 120 seconds for the corresponding request
• X-Cache-Tags: foo, bar: Use foo and bar tags for cache invalidation

Also, some new endoints will be implemented for managing cache:

• DELETE /api/cache/<path>: Invalidates server side cache for that <path>
• DELETE /api/cache?tags=catalog&tags=products: Invalidates server side cache related to catalog and products tags.
• GET /api/cache/<path>: Get cache related to a <path> with its TTL
• GET /api/cache?tags=catalog&tags=products: Gey cache related to catalog and products tags with its TTL
• GET /api/cache?offset=0&limit=10: Gets the path and TTL of all caches paginated.

Note that, cache will be disabled by default, but if it is enabled and needs to be disabled for a certain request, the following header can be specified: Cache-Control: max-age=0, s-maxage=0

Finally, cache managenet will only be supported for REST microservices since gRPC does not seem to support it yet:
grpc/grpc#7945

Migrate critical data to etcd.

Redis is a great in memory storage for our cache features, but is not realiable enough for storing bussiness model.

After creating config module I think it would be nice to have separated modules for

• api: It will grow potentially
• log: It needs to be used from any part of our code. It can grow as well, p.e. if we decide to centralize logs.

It's quite common to communicate microservices by using gRPC instead of HTTP, specially when a bidirectional communication is needed:
https://grpc.io/

We can start this issue by adding a gRPC microservice example:
https://github.com/mmontes11/go-grpc-routes

After doing so, we need to evaluate this options for integrating with gRPC:

• Translate this service to HTTP so we have an unified HTTP API. This can be done with grpc-gateway. The downside is that we lose bidirectional communication and gRPC eficiency.
• Expose gRPC directly by forwarding HTTP/2 traffic. Here it is an example.

Each microservice will be able to specify its own service type when registring

{
   "type": "rest"
   "name": "catalog"
   ...
}

Currently, the following service types will be supported:

• rest
• grpc

Limit the number of request per unit to our microservices.

A good example can be found here.

Each microservice will be able to specify its own rate limiting when registring

{
   "type": "rest"
   "name": "catalog"
   ...
   "rate": {
       "unit": "second",
       "limit": 60
    }
}

Rename /api/{service} endpoint to /{service}.

It will be nice to be able to configure a path prefix for microservices.

Support for passive health checks, also known as circuit breakers:
https://docs.konghq.com/0.12.x/health-checks-circuit-breakers/

We will need to add a new field health to the register payload. For registring a microservice with active health checking we will make this request:
POST /api/service

{
    "type": "rest",
    "url": "http://catalog",
    "path": "catalog",
    "health": {
        "strategy": "active"
        "path": "health",
        "statuses": [ 
             200, 201, 202, 203,
             204, 205, 206, 207,
             208, 226, 300, 301,
             302, 303, 304, 305,
             306, 307, 308, 404
        ],
        "interval": 10,
        "timeout": 5
     }
}

Otherwise, if a passive health checking is wanted :
POST /api/service

{
    "type": "rest",
    "url": "http://catalog",
    "path": "catalog",
    "health": {
        "strategy": "passive"
        "failure_statuses": [ 429, 500, 503 ],
        "failures": 10,
        "timeout": 5
     }
}

Where:

• strategy: Indicates health checking strategy: active or passive

active :

• path: HTTP path used to perform health checking requests
• statuses: HTTP healthy statuses
• interval: Seconds between health requests
• timeout: Timeout in seconds for health requests.

passive:

• failure_statuses: HTTP failure statuses
• failures: Number of failures for considering the serviche unhealthy
• timeout: Timeout in seconds for regular requests.

We will need also a new endpoint for setting services to healthy manually. It can be useful when using passive health checking:
POST /api/service/{servicename}/healthy

As we have the logging centralized in one file when a new trace is printed the line points to the centralized class line. Example:

{"level":"info","ts":1591028358.83824,"caller":"log/log.go:34","msg":"Connected to redis server 127.0.0.1:6379"}
{"level":"info","ts":1591028358.83824,"caller":"log/log.go:34","msg":"Server listening on port 8080"}
{"level":"info","ts":1591028358.83824,"caller":"log/log.go:34","msg":"Environment: development"}

We should find a way to avoid this.

In the near future we will need some mechanism to customize the application's deployment for different environments. So far the most elegant and simple solution that I found is this one:

https://medium.com/@eminetto/golang-using-build-tags-to-store-configurations-d586e23c1dde

Right now, there's no authentication when routing to our microservices. However, it's quite common to centralize authentication in the API gateway.

After evaluating diferent types of authentication OAuth2 seems to be the most secure and used. The user will be able to configure a OAuth server for dealing with authentication. Initially, it will be a env variable: OAUTH2_URL

/api/token requests,/api/credentials requests and authentication challenges will be forwarded to the OAuth URL.

Instead of using a third party authentication service (Google, Facebook, GitHub etc), we can build our own OAuth2 server as a microservice example (like catalog and stock):
https://medium.com/@cyantarek/build-your-own-oauth2-server-in-go-7d0f660732c3
https://github.com/go-oauth2/oauth2
https://www.digitalocean.com/community/tutorials/una-introduccion-a-oauth-2-es

In the future, another authentication methods like JWT will be supported but for now OAuth2 will be the only one.

Add tests to the model layer. We will be migrating critical data to etcd(see #35), so the tests must be easy to adapt after swapping datasources.

Configuring a logger for replacing the log package since it is too simple and does not support log levels.

Maybe in the future will be nice to centralize logs and start using a dedicated infrastucture, for example Graylog or Logstash.

Regarding the log library, here there are some options:
https://stackoverflow.com/questions/16895651/how-to-implement-level-based-logging-in-golang

TravisCI is no longer free, so we better migrate to GitHub actions. We can take this project as an example:
https://github.com/mmontes11/crypto-trade