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...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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...