I'm starting to use NestJS and one doubt came to my mind:
What makes NestJS scalable? What can I do to use its scalability? Or it does it behind the curtains?
Thanks!
Related
So we have decided to use NestJS to build our web-app with, and we have this ongoing argument about whether we should use a Microservice or a Standalone app to implement our queue-interactions module with.
A bit of background - we use Amazon SQS as our queue provider, and we use the
bbc/sqs-consumer package for handling the connection.
Now one approach is to use a microservice, in a similar fashion to what is done here: https://github.com/algoan/nestjs-components/tree/master/packages/google-pubsub-microservice
I believe the implications are pretty clear, and it seems as if the NestJS documentation really pushes you towards microservices here, if only because all the biult-in implementations are for queues/pubSub services (rabbitMQ, kafka, redis...).
On the other hand, you can choose to use a standalone app, which I feel is basically a microservice but without controllers.
Since we opted for using a 3rd party package to handle the actual transport and all the technical details, this feels in a way more appropriate. We don't actually need to send the messages from the messageHandler to some controller and then process it, if we can process it directly from the messageHandler, no controllers included.
Personally, it seems to me that if we don't want to go into details with the transport implementation (i.e. use sqs-consumer package for it) then the microservice approach, while works perfectly, is an overkill. A standalone app feels like it would give us the benefits of separating the "main" and the "queues" processes, while maintaining simplicity of implementation as much as possible.
Conversely, using a Microservice feels more natural to others. The way to think about it is that it doesn't matter whether we choose to implement transport ourselves or use some package, the semantic meaning is the same in the way that we have some messages coming into our app from outside, thus using a custom transport Microservice really is the most appropriate solution.
What do you guys think about it?
Would you use the Microservice or the standalone approach?
And in general, when would you choose Microservice over a Standalone app and vice-versa?
I come from express.js background and pretty new to loopback framework, especially loopback4 which i am using for my current project. I have gone through the loopback4 documentation few times and got some good progress in setting up the project. As the project is running as expected, I am not much convinced with project structure, Please help me to solve below problem,
As per docs, database operations should be in repositories and routes should be in controllers. Now suppose, My API consist lots of business logic along with database operations say thousand of lines. Which makes controllers routes difficult to maintain. More difficulty would arise, if some API demands version upgrade.
Is there any way to organise the code in controllers in more
scalable and reusable manner? What if i add one more service layer
between controllers and repositories and put business logic there?
how to implement it in the correct way? Is there any official way to
do that which is suggested by loopback community only?
Thanks in advance!!
Is there any way to organise the code in controllers in more scalable and reusable manner?
Yes, services can be used to abstract complex logic into its own separate class(es). Once defined, the service can be injected into the dependent controller(s) which can then call the respective service functions.
How the service is designed is dependent on the user requirements as LoopBack 4 does not necessarily enforce a strict design requirement.
I've been reading articles about node.js tips, tricks and best practices in general. I found one that mentioned that it is convenient to really think and approach apps in terms of microservices. I've toyed around with that before, but I'm still not quite clear when is best or what criteria to use.
For example, now I'm working on an app (not for work, but a hobby of mine) to record quotes from books I read. So, I've written node.js API with two routes: A POST route to recording the quote on a MongoDB instance running on a cloud, and a GET route to read quotes.
This is all one single app. Does "thinking", in terms of microservices, mean that I should write two different apps, one for posting, one for getting, each running on its own container?
I'm familiar with Kubernetes, and Openshift so the tech details are not much of a problem. My concern is in regards to how to make a decision in regards to splitting the apps, the separation of concerns bit of the architectural design, so to speak.
Thanks in advance.
Typically, microservices are broken around logically distinct pieces of data and operations. Since both the POST and the GET in your example deal with the same data, and complement each other's operations, breaking the GET and POST operations apart as separate microservices makes little sense to me.
As described, your application is small enough that there's no obvious boundary between components that could be further isolated for better flexibility.
Or put another way, this service already fits most definitions of a microservice, and doesn't lend itself to further decomposition.
I need to create authentication with reactjs and node/express. Previously I did that with redux and right now I am not up-to-date with react-hooks.I saw somewhere in article that this can replace redux.This is little confusing for me, so I need good suggestion about this, and if you can share some article or example of react(updated) node/express authentication,then please share.
Thanks for attention to my wired question))))))
It really depends on what you want to do with your app. When you deal with more complex logic or flows in your application, I personally prefer Redux for making the code cleaner and easier to manage. If it's a simpler flow application, you can definitely leverage on hooks and context to create your own state management as good as Redux.
However, if the application ever has the potential to grow into a complex app (like requires middleware, debugging tools, etc.) I'd recommend starting with Redux so you don't have to switch from hooks into Redux later.
First, understand what Redux offers (and how it helps in a complex app):
https://redux.js.org/
Some related good articles as requested, if you want to build your own redux-hooks:
https://blog.logrocket.com/use-hooks-and-context-not-react-and-redux/
https://gorillalogic.com/blog/how-to-build-your-own-redux-state-management-implementation-based-on-hooks/
I need your help in Loopback Framework.
Actually, my need is how we can achieve Microservices related functionality with Loopback Framework.
Please share any links/tutorials/knowledge if you have any.
I have gone through below links,
https://strongloop.com/strongblog/creating-a-multi-tenant-connector-microservice-using-loopback/
I have downloaded the related demo from below links but doesn't work it.
https://github.com/strongloop/loopback4-example-microservices
https://github.com/strongloop/loopback-example-facade
Thanks,
Basically it depends on your budget and size of your system. You can make some robust and complex implementations using tools like Spring Cloud or KrakenD. As a matter of fact, your question is too broad. I've some microservices architecture knowledge and I can recommend just splitting your functionality into containerized solutions, probably orchestrated by Kubernetes. In that way, you can expose for example, the User microservice with loopback, and another Authentication microservice with loopback and/or any other language/framework.
You could (but shouldn't) add communication between those microservices (as you should expose some REST functionality) with something like gRPC.
The biggest cloud providers have some already made solutions, eg AWS has ECS or Fargate. For GCP you have Kubernetes.
We have created an open source catalog of microservices which can be used in any microservice project using LB4. Also, you can get an idea of how to create microservices using LB4. https://github.com/sourcefuse/loopback4-microservice-catalog