Showcase Microservices backend architecture

[galmail]

This can include how to quickly create a new microservice running on Node, then dockerize it and publish it. Also we could add a Message Broker or Message Queue (for AWS, GCP, Azure,...)

[mcdonnelldean]

We can do this now that the migrations are split. @mcollina Any ideas on a good default second backend service that is tiny but useful for most starter projects? As much as I wanted to avoid it, Udaru is the only one that comes to my mind.

[mcollina]

Having a single microservice is quite useless. Microservices solves two needs: a) independent scalability of various part of the application b) having multiple teams working on the same application.

I would stress the second part, IMHO microservices are not a good architecture for a small solution team that NearForm deploys. That being said, microservices is a buzzword that would be good for sales purposes. Note that without having multiple teams we are falling in the case of a "distributed monolith".

I would leverage one of the key principles of Fastify: it is extremely easy to write a set of routes as a module that can be spin up on its own or as a part of the monolith. I would recommend to follow this path, as it clearly fits NearForm patterns of building a monolith first.

That's a target architecture, possibly with the addition of some microservices to share functionality.

Note that a very important concern in microservices system is traceability, so I would add some support for OpenTracing headers - a client might not use it, but it's a very good demo.

I think it would be good to have:

1. a service sitting behind a queue (AWS SQS?) for non-realtime computations. Maybe the generation of a PDF or of a report. These come up more often than not, and having some boilerplate done would speed up development.
2. a service providing live update via websockets. Not sure how often this happen in our projects.
3. Udaru as a reusable component.