Monolith Hybrid App

[zealous silo]

Hi all.

I'm creating a REST application but we have opportunities for many standalone microservices that might exist within our environment.

One such microservice is one that connects to an external system over TCP, listens for messages, and loads data into our database. I have the service itself contained within a NestJS module, which OnModuleInit, initializes its connection to the external system. The external system is not NestJS...just some legacy TCP socket based application, so I'm not using any Nest abstractions here...just Node's net socket.

Right now, the service is just loaded as a module on our main application. But I'd like to decouple the running instance from our main application, both to ensure the stability of our main application and to reduce blocking. If we have bugs in our module, I'd rather not have it kill our main backend. And I'd rather it not contribute to reduced capacity of our main backend as well.

There is a very small bit of shared code...right now it's just a shared DatabaseModule. Maybe the ConfigModule down the road.

So the question is, what is the best way to deploy this. Nest hybrid app (does this start threads for individual microservices)? Completely separate Nest applications? Or is Nest simply not a good fit for this type of architecture and we're better off just creating small bespoke node applications?

[flat cape]

Nest hybrid app is still a single node process, there's no magic behind it. It just allows you to use http transport along with other transports in a single JavaScript application.

So if you need to decouple it (do you have monitoring in place and can confirm that this part of the system needs to run in a separate thread or separate machine because it's affecting the rest of the system?), you can use worker threads, which will allow you to keep the application code together and deploy it as one package, while taking advantage of multiple cores.

If you choose to separate it to a new application, be aware that the deployment complexity grows rapidly. In that case, I would still suggest using Nest, because it would simplify adopting other shared code - like logging, metrics or tracing for example.

[zealous silo]

It doesn't need to, but since this is essentially a bespoke process that has no actual external facing transport layer, it almost feels as though it shouldn't belong on the main application.

The module/service is basically just a TCP client which gets data from an external system, transforms it, and loads it into the DB for use in our main application.

I suppose one of the main reasons I was looking at decoupling was just in case we have errors in our TCP ETL Service. This is being developed mainly without access to the system so there may be periods of instability. I wouldn't want an uncaught exception in the service to take down our entire backend.

[flat cape]

The choice is ultimately yours. There's no problem with having it separate, only the higher deployment complexity.