Build an API Gateway with NestJs in 10 minutes
This article's intention is to give you a broader perspective into the Microservices arch...
For further actions, you may consider blocking this person and/or reporting abuse
Great tutorial ! -
Just one question I am left with.
In this setup, is it the API-Gateway which connects to the other services (e.g. to service-a, service-b) ? Or are it the individual services (service-a, service-b) that connect to the API gateway service ?
From an architectural point of view, the 2nd solution seems like the way to go. i.e. auto-discovery and scalability of services. You need 1 more service? --> just launch it and let it tell about itself.
And secondly, in this setup, can there be multiple instances of a same service ? I think one of the goals of microservices is to have 0 downtime. My main drive to work towards microservices, is to have the ability to do easier upgrades. i.e. service-a is running but needs to be upgraded. I just leave it on, start the updated version of service-a in parallel. Both microservices connect to the same api-gateway at that stage, and then when it's up and running, I shutdown service-a. So for a short period of time both services are then active in parallel, assuring 0 downtime. - Well, at least that's how it's done in Java Spring Cloud solutions these days.
I am just curious about the limitations of the solution in your tutorial. It would be great if you could elaborate a bit about that.
Hi Bram, thank you for taking the time to go over the tutorial.
Regarding the first question, this implementation uses the first solution, I'm there with you, I believe the second solution is better from an architectural POV and it's achievable by using the Dynamic Modules technique you can find here docs.nestjs.com/fundamentals/dynam....
With the second question, you could do that as long as your microservices are behind a load balancer. As far as I can tell, there's no out-of-the-box solution for load balancing in NestJS but if they are behind a load balancer, the API Gateway won't really matter which instance it's working with.
I hope this clarifies your questions. I've got a ton of feedback with this article and I'm thinking on giving it a Part II, I'll take your suggestion on elaborating these limitations in it.
Thanks again for reaching out, feel free to ask any questions and sorry for the delay.
they are standalone -> they have a walkie talkie on the same channel. -> which is the tcp optionsn declared in the service it'self... The service creates this commjnication channel... Then we inject that service similar to if it was a database or a local class etc..
it's not ultimatly CONNECTED to the microservice there is simply a communication channel opened which can be connected to by the gateway -> or by other services ... or by the client or whatever you want, but it isnt able to control eachother, they just talk to eachother... if the pieces disconnect -> (as long as you handle your errors ) it wont have any real effect on the rest of the system (except for when one depends on the other.)
One last thing i forgot... it's not specific to nest... you could have something that was written in 2010 -> in Java -> or something written in any language -> that can access that connection... (im not entirely sure how simple this is or if it needs to use a sepperate transport method) but the conecpt is the same, it could be comming in from any authorized connection estabished on the service...
Could you make a more detailed example with CRUD ops on a real database? No one runs “hello world” in production
The idea of the article was to show how to interconnect multiple services by using NestJs Microservices framework. In my opinion there are plenty CRUD articles but it's a great idea for a future article to write one about it in the Microservices world.
Hi Daniel,
Great article. I need to integrate AWS API gateway which will be consuming my nestjs microservice. Is there a way we can directly make a call from AWS API gateway and can remove from here.
Thanks.
Hello my friend, I don't know how this comment slipped through.
To be entirely honest with you I'm far from being an AWS expert. From a 10,000 ft view, all you gotta do is creating a new endpoint and set it up to proxy the call to another domain where your NestJs service is running.
Hope that helps.
But how does this solution scale and what about single point of failure problem? Now it looks like you built a distributed monolith.
To learn more about monolith vs microservices you can read an article like this articles.microservices.com/monolit... this kind of architecture scales better but it's indeed harder to maintain.
What do you mean? Nest.js has been built for microservices. Otherwise you can use Java Spring Boot or IBM Websphere for monolithic stuff. The goal is to use microservices. This article about Nest.js is misleading and should not be presented as good practice. This is for lazy people, who make mistakes. There is no advantage in Nest.js. I have been in the game for too long. Why write article how they did it 20 years ago using new framework not built for that?
You say "Nest.js has been built for microservices", NestJs wasn't build only for microservices, it was build to fullfill the need of having a modular structure when writing NodeJs applications. Nevertheless, NestJs comes with a library to implement microservices easily, this article is based on their docs and my experience building this kind of service.
Then you say "There is no advantage in Nest.js", that depends on the context in which you're using it. I hear a lot of people complaining about using Javascript because they have been "too long" in the game, that's cool but I have services running with this in production and they're providing value to it's stakeholders. Each framework has a value, this one is specially good to get started coming from an Angular background.
"Why write article how they did it 20 years ago" things evolve and change, I get that some people like you hates that, but that's just how it is. If everyone was like you "git" wouldn't exist because "SVN" already does the job, and this is just a tiny example.
I feel like you have a strong opinion against NestJs, I'm just explaining how to use it for microservices because I've seen bad implementations of it with NestJs already. You won't find in the article anything saying "If you want to do microservices NestJs is your only choice", I clearly say "We'll be using NestJs. If you havent used it already, you know that it's pretty similar to Angular, and I think it's a clever way to enable frontend developers to do things on the backend as well". My content is mainly focused towards Angular developers.
goooo Danie!
NodeJs al estilo Angular, la neta o que?
si hahhaahaha que bonito
My question is can we implement both express application and microservice app in the same NEST.JS application? is it possible as I am handling my API Gateway elsewhere using something different! I want my NEST application to listen to outside HTTP requests and also listen to events emitted by other microservices,
Please suggest on it as I want both, I want my microservice to listen to outside HTTP requests also and also able to communicate with other services through ASYNC Communication like REDIS or KAFKA RABBIT MQ??
Hi Ayush, thanks for taking the time to go through it.
In theory, you can have an HTTP service AND a microservice inside the same project, in NestJs there's a
main.tsfile that works as an entry point, that's where you usually start the app (whether it's an express HTTP server or a microservice), you can modify the main.ts file so it runs both.Now, my recommendation is to have 2 NestJs applications:
This way you can "send stuff" to your Microservice using an HTTP Service. Is there a practical reason you can't have the two services?
Thanks Daniel! This looks so much like the typical REST Spring app... wow!
I'm glad you liked it!!!
Great tutorial !
But Nestjs offer the posibilty to use Hybrid Application that connect all microservices and can listen to coming http requests from an angular app for example.
The architecture is called "Backend for frontend" and in this architecture microservices can't communicate between each others
I have a scenario where I want a microservice to listen to HTTP Requests and also to the events emitted from the other service. How can I do that ?
You need a socket listening on a port and use the socket.on(event) to call the same method your controller is calling.
You can also use a message queue as entry point and make sure both your http calls and socket events dispatch a message, then you consume from your queue and execute the method. This approach is better in terms of scalability, you could later add a new endpoint in a different service and it will trigger the same behavior.
Thank you Daniel !