I'm new to Node JS development. As an ASP.NET MVC developer, I normally use Repository Design Pattern where I have separate projects for Front-End and Database access in one solution. In addition, when creating a REST api, this can be added to the existing solution. So when publish, it api and front-end is separated by a different route.
I've just created a REST Service in Node JS and it's really simple and I like it. However, when it comes to Front-end I was looking at ReactJS, I've seen a blog (unfortunately, I can't find the link) where it separates the process between the REST service and react front end. I'm just wondering if this is a common design pattern in nodeJS using ReactJS. And if there's a benefit on doing this. Specially nowadays, Full Stack developers are a common thing. I can see the benefit of it from a maintenance stand point but I'm just wondering if there's a benefit in terms of server resources i.e. memory, cpu. Should the OS handle 1 vs 2 nodejs process? Will this differ from using linux vs windows?
I see a huge benefit of separating the frontend from the backend so I would propose you to have your Node backend running in its own project and let's say a React solution running on its own. The React client can then consume that API together with other APIs later. By separating you have the benefit of scaling later.
If you've already built the REST service in node, you can access it via proxy in the React project's package.json by adding
"proxy": "http://127.0.0.1:5001/"
It helps manage CORS issues.
Related
I am relatively new to mobile development and would like to know further information about this specific topic.
I am working on a React Native based mobile application and am now getting around to implementing the back-end for this application. I will need to send data back and forth from the client (the mobile application) to the server (a cloud server). I am aware I can accomplish this with technologies such as a MongoDB database or a Firebase database, however, I would like to try to implement this on a personal cloud server.
How would I go about establishing a connection to a server in node.js so that I may send and receive data?
Thus far, I have looked the node library Express.js, but I am unsure if this is of any relevance as to what I am looking for in terms of a solution to what I am trying to achieve.
First of all, I think you need to have a backend project for making your backend you choose Nodejs
Node JS is a fast JavaScript runtime environment that we use to build server-side applications, but it does not know how to perform serving files, handling requests, and handling HTTP methods, so this is where express js comes in.
Express JS is a Node.js framework designed to build API's web applications cross-platform mobile apps quickly and make node js easy.
Why Express JS?
Express was created to make APIs and web applications with ease
It saves a lot of coding time almost by half and still makes web and
mobile applications are efficient.
The reason behind creating an express framework for node js is:
Time-efficient
Fast
Economical
Easy to learn
Asynchronous
After completing your backend project with either postgres or mongodb database connection and node js you can deploy it to your cloud server and access it from the apis form the front end mobile or web applications.
Another thing I want to mention you can also create some web pages using node handlebars as well.
I am planning to build a rest api in node that will be consumed by a react-native mobile app(using JWT tokens) and reactJS web app(admin UI using sessions/http-only cookies). Would you advise me to write this directly in express or use a framework like nestJS?
How should I structure/architect the project to meet the above requirements taking into consideration, ease of Management, autoscaling, hosting, etc?
Would you consider dockerizing the node application over running node directly on the server? is there any performance gains?
should I break the project into 3 repos ie:
rest api | backend webUI(reactJS) | mobile app (react-native)
or
rest api + backend webUI(reactJS) | mobile app (react-native)
Ideas/advises are welcome please, thank in advance.
I'll try to answer based on my work experience in both:
Structure/architecture of the project depends if you are working alone on the API or in teams (express gives you freedom in code however you like but it's a nightmare if your application grows and gets bigger in complexity with a big team trying to maintain it), NestJS has a structure to follow for you and your team (if MVC model gets the job done for your use case)
Docker use is for ease of deployment for both (if you know what you are doing) and can have better performance when running multiple instances. the catch is in the production server with a docker database backup and recovery are harder and if you need migration/restructure after deployment in prod welp...you gonna cry
I always separate (API | web UI | mobile app) so I can debug them easily separate domains of errors but talk to your team and provide docs for what they want in the Rest service if you are alone and the WebUI is not exposed to the same user base as the mobile app then it doesn't matter really
We have a web app (CRM type) working on Linux (Debian) with Apache, MariaDb and PHP for the backend, and AngularJS (1.x) for the frontend.
Thinking about a redesign, I need advices on a solution I have in mind, but I'm not sure it would be relevant...
A new website (e-commerce) will come along the CRM and use directly or not (API) the same database.
So my first take would be to put the MariaDb on a dedicated VM. It uses much ressource right now, so much more with another app using it.
Then the CRM and website could connect directly in remote (too risky?) or call an API. I guess the second solution would be better and means I could put my backend PHP part (already working as an API for AngularJS) along with the database, on that new VM.
I guess Debian + Nginx would be a good choice to go with them.
I prefere PHP to handle databases 'cause I'm used to it.
On the other hand I would still have AngularJS alone, a deprecated JS framework.
One thing that was hard to work with, about AngularJS/PHP, was that sometimes I needed to format data for Angular from PHP, and vice versa. It wasn't very clear where to put that formating, 'cause the backend was more about the database and not the frontend, and the frontend more about layout than PHP ORM ans design.
Furthermore, we'd like to keep the CRM as a SPA (Single Page Application).
My take on that would be to go on a MEAN stack, without de M (MongoDB), starting from scratch, just keeping Debian and installing NodeJS, ExpressJS and Angular or another JS framework (Vue, React...).
A hole JS stack to have the same language and gain speed and performance with many little transactions with the server (assets, calls and promises to retrieve data from database). Also to learn more on JS and NodeJS particularly.
NodeJS to create the environnement and a web server, in place of Apache.
Angular (or another) to put data into HTML, and have the less treatments possible.
ExpressJS to be that intermediate part I was talking to, the place where formating can be performed: retrieving data from the views, formating them, sending them to the API, handling the response, formating it if necessary and returning it to the view.
It means I would go from one VM with:
AngularJS (frontend) -> PHP framework (backend) -> Database
To two VM with:
Angular (app frontend) -> Express (app backend) -> PHP API (database backend) -> Database.
What do you think of my use-case and the solution?
There are several benefits to splitting up your services, but almost equally many different solutions, so you need to ask yourself what your goal is. Performance? High availability/failover? You might need a lot of VMs, geo-redundancy, load-balanced VIPs, etc.
You can also look into making containerized services with Docker.
You talk about moving the database onto a separate VM, but that it might be risky. Why? If they are both on an isolated network, it should not be an issue.
If you're looking for stack advice, since you're talking about a full remake, I would recommend something both stable and modern like Laravel + VueJS for the web/API part. You're already comfortable with PHP, and a setup with Nginx will probably be much faster. But of course, there are almost infinite combinations to choose from these days.
As for the "direct or not" DB access: Having a versioned API is always a benefit.
Serving the SPA frontend will require very few resources, so your bottleneck will be between the API backend and DB. You can make it scalable by putting the API behind a VIP and load balance with something like HAProxy/Nginx.
I have built a node js app but for simplicity I made two different apps. one does the database product management job for the React frontend such as adding, updating and deleting products and the other does the authentication part with JWT token which is saved in local storage of frontend. in this way I think I'm more comfortable in managing and editing the code I wrote for them because of simplicity and small app size. should I merge the two node js app together?
I know people separate backend from frontend but it came to my mind why not separate backend into parts?
It is not uncommon to have a separate service for authorization token and resource service (such as OAuth):
In your case, that looks like a small app, you could definitely group the two to save one process, and refactor later if needed.
If you keep them separated, you will later have less chance to mix the concerns.
You can also look at creating distributed npm features that you plug into your app (as any npm dependencies). This way, you keep things separated and modular.
In this case, you could check lerna to build a monorepo for your backend service
My team has developed an iOS and Android App for our project while we use node and socket.io for back-end. We want to move to meteor so we can have a front-end with Angular 2 easily connected with the back-end.
But we want to rewrite the back-end with Meteor so our Apps can use it. And after this create the front-end.
My question is easy, in Meteor front-end and back-end are done at the same time? Or can we first build the back-end and after this the front-end?
Yes, this is possible although it would feel a bit awkward to an experienced Meteor developer.
The Meteor "back-end" exposes the following:
managed collections: these are the definitions of the mongodb collections that will be used by your app to persist data. Note that some of these can be private to the back end, i.e. not exposed to the front end at all.
publications: these are the filtered/projected "views" of the collection data that the back-end will share with the front end on request (the form of the request is a subscription). Published data is synchronized bidirectionally with the front end asynchronously over WebSocket. This is the magic of Meteor's DDP which IMO is Meteor's core innovation.
methods: these follow a more traditional request-response pattern. You can have as many of these as you want and each can accept any number of parameters including objects. Meteor can also do latency compensation for methods which means that the method is first simulated on the client and the UI updated while waiting for the server to come back with an authoritative result. If the server result differs then the UI is patched up with the authoritative result. This makes database updates appear instantaneous to the user while providing eventual consistency.
If you like you can even build traditional REST endpoints with Meteor but then you would be missing out on the reactive sugar. These can of course be useful for other integrations however.
Like nodejs, Meteor encourages developers to tackle the full-stack. You're less likely to segregate developers into back-end and front-end functions which gives you a lot more flexibility.