Extract a base microservice layer to reuse for all our services

[humphd]

In #1636 @raygervais and I have been iterating on our first microservice, a simple image service. As we start to work on other services (#1627) we're going to have to solve the same problems over and over again:

• env handling
• setup express app
• security (helmet, csrf, cors, etc)
• various base middleware
• logging
• error handling
• start a server on a predefined port
• graceful shutdown (probably crash on error so docker-compose can restart)
• healthcheck route

I'm sure there's more, and added to this we'll have to maintain versions of all the dependencies.

Let's find a way to write this code once and then use it as a base for all of our apps. I'm imagining something like this:

src/
    api/
         _microservice/  <-- our base microservice app
         service-1/  <-- a service using _miroservice (e.g., image service)
         service-2/  <-- a second service using _microservice (e.g., auth service)
         ...

In service-1 you'd do something like this:

// Pull in the _microservice base to get our pre-configured app
const { app } = require('../path/to/_microservice');

app.get('/', (req, res) => res.json({hello: 'world'}));

What I'm not sure about is the implications for dockerizing the code when we do this. Probably @raygervais knows how, and can guide us.

I'd love for each service to as simple as possible, and focused on the endpoint requirements alone.

We can probably start this by making the image service in #1636 work this way, then use it in the next services.

[raygervais]

@humphd, did you plan on updating the image service first with this architecture?

[humphd]

It might be smart, what do you think? Then others can focus on their service features vs. solving these problems.

[raygervais]

Agreed, plus we can add a base Dockerfile into _microservice for reference as well (adding to your list).
The ports we are going to have to juggle, so my idea: keep a .env file in the root directory of telescope (or config folder) which gets copied on build by Docker into the various containers. This way, we can define ports / configurations in a single place.

Logging means getting Kibana configured and in the mix, perhaps exploring https://medium.com/the-sysadmin/visualize-traefik-logs-in-kibana-c53fb2aac070 would be beneficial. I can do that today perhaps so we work in parallel and I submit PRs against your POC again?

[humphd]

OK, great. I like your idea of always copying the root .env into each, so we can continue to configure the entire app like we do now, and specify port numbers for services in there.

Yeah, I really want to get Kibana/Elastic/??? tied in with all these services and Traefik so we have visibility into what's happening. #1348 is related.

[raygervais]

I'll start on #1348, based on the work we are doing here

[humphd]

Finished with https://github.com/Seneca-CDOT/satellite and used in the new image service, see src/api/image.