in my team we use NestJS for our backend. We want to use microservices architecture and I've seen there is a built-in microservices support in NestJS. After read the documentation I've got a few questions about this feature:
Should I create microservices in the same project or in separate projects?
Why even use createMicroservice over NestFactory.create? Using createMicroservice also makes me to use #MessagePattern and use an emitter to send messages - which is okay if my microservice gets messages using queue (like RabbitMQ), but I can't create REST API in my microservice, so it makes it harder (or impossible) to call NestJS microservice from non-NestJS microservice since it relies on NestJS MessagePattern.
Thanks ahead.
It is not necessary but I personally create separate projects within a workspace.
Calling createMicroservice is compulsory because nest needs to know what kind of controller you have and what behavior do you expect. In addition, you should avoid implementing rest API in all services; it should be implemented just in gateway service which is responsible for API layer, and it is a bond between microservices and outworld.
For having a good notion about microservice implementation with NestJS I highly recommend you to take a look to this repo:
https://github.com/Denrox/nestjs-microservices-example
Related
I have running my backend services based on Monolith Architecture using Node.js express. The application is getting big and I need to migrate from Monolith to Microserivce Architecture.
I decided to use REDIS pub/sub methods for messaging purpose among API Gateway and microservices. What is sure is that, I need to create a topic for every single API available under each microservice and then start listen for emitted event from API Gateway to interact and return appropriate data from microservice to Gateway and return that to end point.
For Instance, if an end point call api for gathering products list, there must be a listener opened inside the product microservice and listening for list event to generate the list and return via gateway to end point.
The question is, is there any solution available for me to either do not create event for every single API inside my microservices or there is no way for me and I need to create event listener for every API that I have?
There are some patterns to refactoring a monolithic application to microservice. for example, you can use the anti-corruption layer to start it and the start to separate your bounded context one-by-one to a new Micro-service. Then you can use a gateway to handle your client request and authentications. To implement a fast dedicated Gateway you can use Ocelot. But don't forget that to implement a Microservice structure its important to know details about Domain-Driven Design (DDD) and some other patterns like CQRS and some Message brokers like rabbitMQ.
to start you can read and follow the below links:
Refactoring a monolith to microservices
Monoliths to microservices using domain-driven design
This could be a silly question but I want to confirm about it. I am a backend Laravel developer and have created my website. Now I want to create mobile mobile apps but have no knowledge of front-end.
Due to lockdown situations I want to use this time to create the backend API for my apps. Now I want to know is it ok or a normal practice to create APIs without knowing anything about front end. (Like is it possible that I just create all the endpoints now that are throwing data in JSON and then the front-end developer will use them to integrate in the front-end? Thanks
P.S: I dont know how the app front-end will look like but I know what data will be needed in each page/view.
I think you can do this easily with graphql.
A Frontend dev and also beginners with Apollo in the frontend can easily introspect and build the stuff.
If you can choose your Frontend stack there is no problem with rest either.
I always do the Frontend first approach.
Mocking the data for graphql types and building the api later seems to me the best workflow ever.
See ya. Much fun with your project
Yes it is possible very possible to do that it would be nice is the API is well documented using postman or swagger for a better experience when frontend engineers want to integrate
Many API's in the world today are never consumed by a browser or app on the frontend, sure it can make life easier knowing why you are building it.
But at the end of the day, a good API is simple and easy to understand. It just allows a developer to fetch data from a system but normally with some idea about each type of request.
For example, if you had an API for a university the endpoints could be as follows:
/pupils => Get/Sets pupil data.
/teachers => Get/Sets teacher data.
/classes => Get/Sets class subjects and references ID's of both Pupils and Teachers.
So if you wanted all the Pupils in a given class you would query the /classes endpoint and then for each Pupil ID you would query the /pupil endpoint.
Sometimes not having a frontend makes the API even more generic because you might think differently when you do not have a frontend.
I have a never ending discussion with my manager about the usage of AWS Lambda. I would like to get some help from one of you guys.
I am a bit hesitated to utilize serverless architecture for production level projects yet. First of all, its a bit time-consuming to test what I am building in the local setup. Even if we can test the code through the unit testing, we cannot remove the possiblity of faliure of mocked request and response objects. The fact that I cannot invoke the lambda in my local setup makes me very bored when I am testing my Lambda-written API during the development process. Secondly, as far as I know so far, there is no promised SLA for AWS Lambda for its availability and reliability. This just make me kind of hesitate adopting Lambda to build RESTful API.
So now what I do is to use Lambda only the case when to catch events triggered from AWS. For example, to do something after a user uploaded his profile picture to S3 bucket or to do something after a user registered throuh Cognito.
However, what my manager expects is to mix my Node.js API with AWS Lambda for a single project. From my perspective it totally doesnt make sense. Once we have set up Node API on EC2 instances, I think it will be more productive to think about setting up auto-scaling or how to utilize all the resources running on the current EC2s. But my manager insists me to set up both Node API and Lambda API altogether. For example, the services A and B will be served by Node API and the services C, D, and E by AWS Lambdas.
I tried it before, but it caused a lot of confusion to me. I feel like it will be better to choose either Node API or AWS Lambda API when building an API instead of mixing them together.
I don't want to say that my manager is totally false and I am right. I want to just have a clear answer in this case. I would really appreciate any comment and answers on this situation.
Just adding some thoughts on the previous answers:
First of all, its a bit time-consuming to test what I am building in the local setup. Even if we can test the code through the unit testing, we cannot remove the possiblity of faliure of mocked request and response objects. The fact that I cannot invoke the lambda in my local setup makes me very bored when I am testing my Lambda-written API during the development process
For sure you can build, test and simulate a Lambda Invoke in your local environment, it's just a new paradigm and there's some tools to help you out.
Secondly, as far as I know so far, there is no promised SLA for AWS Lambda for its availability and reliability. This just make me kind of hesitate adopting Lambda to build RESTful API.
AWS Lambda operates on the AWS "compute layer" infrastructure, so I believe if they face an issue on the compute layer, for sure your EC2 instances will also face an outage.
Once we have set up Node API on EC2 instances, I think it will be more productive to think about setting up auto-scaling or how to utilize all the resources running on the current EC2s
I don't think so. The serverless stack scales with zero effort, you don't need to manage infrastructure.
I tried it before, but it caused a lot of confusion to me. I feel like it will be better to choose either Node API or AWS Lambda API when building an API instead of mixing them together.
Welcome to micro and decoupled services! Where developing the service is easy, but managing the whole infrastructure is hard.
Another thing to keep in mind when talking to managers about architecture: Cost
It's hard to argue and makes every manager's eyes shine when they see the possibility of running their businesses with a low cost. And having your service running with a serverless stack is really cheap.
Bottom line:
No, it's not a bad idea to mix resources as your manager wants.
Yes, it's easier to just get a framework to write the api, setup an EC2 instance and a auto-scaling group.
Yes, there's a heavy lift when decoupling services, but it pays its price when running in production.
OK let's go one by one. First thing first. Your first problem is to test Lambda in your local and it completely possible to do with SAM.
Please have a look on - http://docs.aws.amazon.com/lambda/latest/dg/test-sam-local.html
The most important design decision, If your application is monolithic and you don't want to redesign it to microservices then stick with EC2.
Next regarding your design for hybrid API (Lambda and EC2). I don't think that is an anti-pattern or bad idea to do. It completely based on your requirment. Say you have an existing set of API's in EC2 (May be monolithic) and you want to slowly migrate it to serverless and micro services. You don't need to migrate it all together to serverless. You can start one by one. Remember the communication is happening through Http and it doesn't matter if your services are ditributed between EC2 and Lambda. In micro service world it doesn't matter services are in same server or ditributed across many servers.
The communication speed has drastically changed over last few years and that's one of the main reasons of emergence of micro service.
So in a nut shell it is not a bad idea to have hybrid API's but completely based on your design architecture. If monolithic then don't go for Lambda.
There are instances, where you do need to run Lambda and EC2 instances together (E.g Monolith to Microservices migration projects, NodeJS with Express as a WebServer) which can make sense.
There are multiple approaches to achieve this. Two common approaches(For request-response) are to use.
If you plan to serve only RESTful APIs from both Lambda & NodeJS EC2 instances you can use API Gateway as a proxy for both of them.
If NodeJS EC2 instance is used as a WebServer to serve both dynamic pages & etc, then you can use AWS CloudFront as a proxy & still you will require API Gateway to connect with Lambda.
Note: For asynchronous workflows, you can use Lambda along with other AWS services such as AWS Step Functions, SQS, SNS based on the nature of workflow.
I have examined and practiced on creating Rest Api's with loopback and ExpressJS seperately
While Using Loopback;
It was really time consuming to read all the documentation and learning loopback specific stuff
It also enables you to create your Api in a short period of time and has lots of magic things inside it.
I saw that if I face problems while developing with loopback. I usually get stuck in finding answers from community.
While Using ExpressJs
You write almost every api endpoint in same format with lots of copied code.
You are comfortable with it and can do anything with ease.
But time consuming if compared with loopback.
My point is to utilize best parts of both ExpressJs and Loopback
So my question is "Does it make sense to use Loopback with ExpressJs and also use Mongoose?"
Related with my question Loopback has a documentation about adding ExpressJS route in Loopback application. Loopback with Express Route
If it makes sense is there any recommendation for folder structuring ?
As #Jspdown wrote in his comment to your question Loopback is really based on Express, so you don't need to make choice between them.
When you work on your application using Express and produce 'lots of copied code', soon you start to optimize it and in fact develop your own framework. So this is exactly what Loopback team already have done for you.
Thus the choice is not Loopback or Express but it is - to invest into study ready-made framework or to develop your own framework. As for me I think that if you are working on relatively simple projects and/or quick prototypes or going to change your programming tools soon - don't study, just do. But if you are working on large, mission critical system in long-lasting project - Loopback is helpful.
I wrote a REST API in Node.js (with Express)that implements a queue with some dequeue/enqueue functionality, and the next step is creating a web view for that API.
I am really new to javascript and Node.js , can i have some pointers on how to implement it? is there a framework I can use to integrate the api.js i built with a front-end?
When you wrote a REST api using nodejs and the expressjs framework, you are perfectly prepared to use the complete MEAN stack, which implements angularJS for frontend services.
Angular offers a complete REST implementation (called ngResource). Install via npm.
With the angular resource service you get your frontend interface (to interact with your backend) out of the box (except a few adaptations you'll have to make, e.g. to make it work with Mongoose, which is used to make the access to your MongoDB more comfortable).
You'll find a few superb tutorials, as this one and others on scotch.io are some of them. Google for 'api rest angular resource mean ...' in different selections ;-)
Other links that helped me a lot:
Tutorial from Angular itself
Thinkster.io - complete MEAN stack overview with examples
a helpful tutorial with good examples from Frederik Dietz
Buecheler comes out with this great tutorial, but its more about the backend side - as you might check your code againt the basic standards of a REST backend implementation.
Those are some of the links I noted and that could find ad hoc.
EDIT:
As your headline suggests you are searching for an UI, I suppose IBM Strongloop might be a good hint for you. IBM is strongly interconnected with the development of ExpressJS and offers this API and UI for probably all data concerning questions of your Webapp.