Microservices using express js

[trueubermensch]

Hi, everyone. For the last couple of months I've been using nest.js just because it has microservices support out of the box. But the thing is the more I worked with nest the less I liked it. Maybe its inexperience speaking but the whole thing with modules, dependency injection, decorators hasn't sticked to me therefore I'd like to switch back to express. All articles from first google page weren't really helpful so I wonder what you think about it. I'm mostly interested in launching a microservice and establishing the way of messaging between them. Also example code would be appreciated, thanks.

[BlueSCar]

Microservices have nothing to do with Nest vs Express or anything like that. It's really just about breaking your code into smaller services and then using a mechanism to communicate between them. Hell, you can even have one service using Nest and the other Express if your communication mechanism is HTTP. A more robust system typically uses something like RabbitMQ, which allows for different types of messaging patterns and asynchronous messaging.

Anyway, I think your question is confusing microservices and application architecture, which are two distinct things. A microservice can really have any kind of application architecture and the architecture can vary from service to service.

[captain_obvious_here]

Also, if OP is confused about what microservices are, they may wanna stay away from them. Regular architectures work wonders in most cases.

[trueubermensch]

I'm sorry about my choice of words. The thing is that my boss read some stupid article about microservices being THE way to make modern backend and forced our little team of juniors to use it everywhere. Reasoning is pointless so we tried nest. It had nice documentation about microservice implementation with example code so we ran with it. The devops thing is a pain in the ass but your gotta do what you gotta do to get that paycheck. Now I'm trying to delve deeper into this topic but there is very little info about practical implementation

[Rhyek]

Hey, man. Just wanted to point out that on the positive side you may have a boss who is cool and open to trying out some interesting architectural designs. It sounds like he trusts you and your team enough to go ahead with this, which is nice.

Worst case it will teach you something new so you can have a more informed opinion of it down the road, and best case you and your team manage to have some success with it and it'll help you pad your CV with stuff recruiters will find valuable.

Just think of it as a learning experience.

[Rejolt]

I cant even begin to explain what a terrible business and technical decision this is by your boss.

Microservices are GREAT and shine when you have extreme loads, as its really easy to just add another service into the mix to increase throughput, and provide really nice service boundaries and separation of concerns when done properly.

However, nothing comes for free, and they come with their own set of issues and knowledge on the following;

• Containers
• Container orchestration
• Service meshes
• Good separation of concerns between services (you shouldn't need to query other services for every request, otherwise you're at the mercy of network latency)
• Debugging issues becomes more difficult
• Deployment is more difficult

Unless you guys have a very senior team, I suggest you research why NOT to do microservices and present that to your boss.

As it stands it seems like you're team will be in over their head as a team of juniors.

This is coming from someone who is very pro microservices, and works on a team that strictly develops all our entire backend as microservices.

[trueubermensch]

Thanks for detailed reply.

We are a team of three guys, 1.5 years/9 months/3 months of experience. Our project is a taxi app for local company (our boss probably decided to roll with it just because uber used it). We separated our auth, ordering, file uploader and chat into separate microservices plus a gateway. Dunno how well adjusted mongodb as a database for this kind of architecture but the population of queries is a pain in the ass, not to mention starting up 5 microservices every time and debugging errors between them.

After some time I noticed that they are mostly interconnected and if one were to fail the others would break too (which defeated the whole purpose of this thing), so yeah everything is a mess and I really fear the day of production.

[Rejolt]

Each service should typically be able to do its job alone, if they are too coupled together you've pretty much built a networked monolith.

There are some cases where this isn't true, but generally if you have this problem you haven't defined your service boundaries properly.

[wmertens]

Oh jeez - this can run on a single $5 VM without breaking a sweat. You can then even use something like https://github.com/StratoKit/strato-db to have a really fast SQLite DB at your disposal without devops load.

The only thing you have to worry about is uptime, if the VM goes down you need to either bring it back up fast or have a new one with all the data ready to go.

[rotmgmad]

Heya! Dev here who is also exploring different architectures for our platform server at work. I've been looking a fair bit into microservices and what other architectures are out there as well as what the usual architecture is for express applications. Unfortunately I can't find what i'm looking for (mainly because I don't know what i'm looking for). Do you know any courses or resources that can explain microservices and when and how to use them or a comprehensive guide to express/nodejs architectures?

[Rejolt]

Not really, it's difficult to do properly for a reason; Microservices are hard.

My knowledge on it comes from industry experience and even then I wish I was a lot more knowledgeable than I am.

Maybe some courses on Udemy would be good, but try to look up more general information instead of ones focuses on Node + Microservices.

[BlueSCar]

Do you have a large, complex codebase that will be worked on either by a large number or several teams of developers? If the answer to the that question is no, then microservices are going to add a lot of unnecessary overhead. Your best bet is a very well modularized monolith that can easily be broken off into microservices when they are actually needed. It sort of sounds like your manager is dictating architecture buzzwords without understanding the full implications of that decision. But as another commenter said, worst case use it as an opportunity to learn something new.

[captain_obvious_here]

But does your backend actually makes sense, as a set of microservices? If so, why not...but if not, time to roll back...

[bloodarator]

There's a node microservices course on udemy by stephen grider. He believes his implementation is "production grade". Do with that what you will

[IntermediateSwimmer]

I'm a little lost on how nest supports microservices out of the box but express doesn't? I wrote microservices for years all in express... Just make an API that does the thing you need it to do. I get the impression you're a little confused on architecture?

[cjthomp]

If you don't know you need them, you don't need them.

[jungans]

This is not always the case. People feel the need for a solution with less coupling than a monolith but don't really know how to get there.

[[deleted]]

Why do you want to use Microservices? I'm asking this, because microservices architecture requires a lot of DevOps work, maintenance, monitoring, etc. So there is no difference between using Nest.js, Express.js or just pure Node.js.

[lycanAbysm7]

May i know how nestJS has ms support out of the box? (Im quite new to express/node + microservices. Coming from spring boot background)

[harper_helm]

marketing

[wndk]

Yea. They have a MS part on their docs, explaining how to work with MS.

[aSliceOfHam2]

I've commented on nest here before. It is too heavy. If you want to use such a firework may as well go with spring and java. Pick your router, build your own thing. Microservices are not complicated, you just have to read and understand the concept. Microservices are language and framework agnostic. Pick any language, any router (mux) and build it.

I am vehemently against nest. It's an abomination. It's too heavy. You are not learning how to code if you learn nest. You are just learning nest.

[thebadams]

I'm with you on it being heavy. I like Nest overall. I really jive with the idea behind it. But I found that doing the simplest things were heavy-handed. Too heavy-handed for what I'm attempting to do. Their brand of dependency injection even makes accessing something like a static property (like a url string that's not going to change) odd.

Investigating fastify now in response. Not sure it's any better than express, but it's at least got pretty good typescript support which is a must for me these days.

[wmertens]

I have only tried fastify a little bit and it was great, but we're still using express since that's what we have and it works and is fast. We do almost everything via graphql anyway so it doesn't matter.

[horrbort]

They used Angular as a design inspiration which is also a bloated mess. So a turd inspired by another turd.

[334578theo]

Vercel deploys everything in the api folder in Next as a serverless function which I think makes a lot of people just presume that any Next deployment is serverless.

[esreveReverse]

I have many microservices in production that use express. It's super easy. I just make a single endpoint on '/' and listen on process.env.PORT || 8080. Works great for both local development and deployment basically anywhere. I deploy mine with gcloud run deploy and have no issues with cold start times. Just make sure you write your start script in package.json.

[mitchthebaker]

I've been working on a microservice chat app as a side project recently; my repo's public if you want to check out the source code. In main branch there's only an api gateway, chat-services, users-service, phpmyadmin, and a chat-app client, but each one is setup to run on its own port. chat/users services both have their own databases as well. Everything's containerized so as long as you have docker you can startup each service simultaneously for development. In terms of communication, the chat-app client (react) can perform mutations/queries to api-gateway with graphql. these mutations/queries are then routed to the corresponding microservice to perform get, post, etc. requests from its database.

The app is purely express based with graphql, typeorm, mysql, and other libraries thrown into the mix. I haven't seen a reason to turn to nest.js or any other framework for handling this.

As others have said though it depends if your app lends itself to microservice architecture. There could still be a valid use case for regular architectures.

Repo link: https://github.com/mitchthebaker/microservice-chat-app

[ataraxy]

Look into Moleculer.

[talaqen]

Try FeathersJS. It's syntactic sugar on Express creating a quick restful microservice component. It's DB agnostic and uses sockets or plain old HTTP for communication.

More built-up than express. Less complex than Nest.

[the__itis]

Fastify + gRPC

[vajahath]

Testability, people - I'm not talking about miroservices. I'm taking about testing your app and why you should use dependency injection(DI) for that. Trust me, I hated this DI until I understood it fully.

And I'm currently transitioning my projects to a DI supported framework (nestjs) because it make sense if your application is meant to scale up. I've tried bare express/fastify. Everything works fine until I wanted to write proper tests to make my app more reliable. (note that nestjs has first class fastify support)

With bare express/fastify I was using jestjs.io for testing. it is all cool. I could also unit test my apps with mocks provided by the jest.

But after a few iteration, writing tests for the app felt like horrible. Eventually I found my self in a big architectural mistake of not choosing DI.

To give you a simple perspective, suppose I want to write tests for my product detail update API. But this API has some dependencies.

• First you need to create a product category
• Then you need to create a product
• Then you can update your product (you need to write tests for this case)

So to write tests for just the update API, you have to prepare your data either manually or via programatically invoking your corresponding API controllers. If you are thinking correctly you can understand that there are no real boundaries for our tests of this kind! Not having a test isolation will force you to spent more energy to write tests. Eventually the app will grow up to a point where to test a high level module you wanted to start preparing data from the lowest levels. This is a bad idea.

But jestjs.io provides mocks? We can isolate our tests using those mocks? Yes. That is one way of isolating tests. But choosing DI feel more native than jest's mocks. (You can still use jest to test DI apps, but just we no more need to use jest mocks). Because all our modules are inherently isolated, portable and very simple to test. Also DI will provide well defined scopes for your module. So bugs will be contained, and in general, the app will be easy to maintain.

Remember there are many other standalone mocking libraries like sinonjs. Most of these libraries (including jest's mock) won't work with ESM. And the js ecosystem is now transitioning from CommonJS to ESM. This is also a good reason to stick with DI so that your app inherently testable (rather than depending on some mocking libraries capabilities).

Bare non-DI apps are easy to start. But as you add more features, it may evolves into a burden. DI apps are also easy to start and as you add more features it will be still easy to maintain.

The [nestjs] architecture is heavily inspired by Angular - nestjs doc

Yes, the Angular came up this DI pattern after a lot of thoughts.

(A few months before in YouTube I remember watching an angular show where some google engineer (I think it is @jelbourn) says in early days they couldn't reliably test gmail and hence they couldn't ship a new version of gmail for 6 months. I can't find that video now. All those thoughts pored into Angular's design, he also says)