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
Related
I saw the approach where the frontend and backend applications are located in the single project and the frontend application generates bundle.js that is used in index.html served by backend controller.
I also saw an approach where frontend and backend applications were completely separate projects and frontend knows the endpoint of the backend running separately.
Which approach is better? What should be considered between choosing one approach or another?
You can have two approaches as you have mentioned
The front end and the backend in a same project.
The front end and the backend in a different project.
I would like to highlight the differences for both
For the point 1 Its suitable where
You have small scale projects.
Where everything can be managed in the same project like not too much of backend is needed in terms of maintainibilty.
If the there is a single front end using a single backend project.
Will elaborate the third point like consider if you have different front end projects communicating with the same backend.
And the main point is you want to expose your apis publicly then its not recommended for the first approach
The 2 approach is something
Where you write sharable apis , maintaibility is needed across the teams too much of backend is required and maintained time to time etc... For example like microservices architecture....!!!
My question is more of a query as to how people deploy production web apps now / best methods etc.
Currently, we are looking to put into production a web app with a NodeJS backend using express as well as a frontend we have made.
Does it make sense to split the frontend and backend onto their own separate server, or to render the HTML files directly from the NodeJS backend on one server?
If you have any other suggestions please list the pros/cons and how a dev team of multiple people can easily manage the source code as there are separate people split up to just frontend and just backend.
Note: This is the actual web app, not a static site or landing page
I went through this decision process recently, and I chose to deploy static and dynamic parts of my system together.
How to decide this question?
Are your front- and back- ends tied closely together? Do many front-end changes require corresponding back-end changes? If so, that's a reason to deploy both in a single server. That was my situation.
Does it make any sense to serve your static HTML / Javascript / CSS / image resources using express's static-object server functionality? It might: Express lets you do good things like .js minification, on-the-fly translation of .less or .sass files, and so forth. It also has good facilities for handling CORS, rate-limiting, and other infosec features. If you want those things, that's a reason to deploy both in a single server. That, too, was my situation.
Will you rig up a reverse proxy (nginx) server facing the network? That's a tricky enough configuration task that you probably want to do it once rather than twice. That's a reason to deploy both in a single server. My situation.
Do you have many many static objects to serve? That's a reason to deploy the static objects and the web app separately: Pure apache or nginx is more suitable for serving static stuff than node. I only had a few static objects.
Is there a chance, in your devops, that two separate deployments will make things more complex and less reliable? (Will somebody forget to deploy both static and dynamic?) That's a reason to deploy both in a single server. I did that because I want test, staging, and production deployments to work identically.
Git and other source-control systems are robust enough to allow teams to contribute to a single repo without stomping each others' work.
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.
My application structure consist of few parts. Public API, Admin API, Admin Console (GUI), Private API, Auth API (oauth2, local, socials), etc. They kinda different each to other, but using the same models. Some routes going to have high number of requests per second and couldn't be cached.
I'm interesting in best practices to split everything properly. I'm also opened to another frameworks or even io.js.
Right now I got 3 variants:
Create separate apps.
Group controllers by folders, and find a way to group routes.
Create another instance of sails app and run it into another process (So I can have all controllers, models, but how should I organize subapp structure using this way?)
I think most answers will be opinionated, but putting controllers into subfolders is the easiest way to share models. (easiest but not only)
And you can easily run policies based on those subfolders as well.
However you really need to flesh out more aspects of your question and think about if there will be more shared (like templates or assets) than different or if differences would prohibit a shared app. Will they all use sessions or will they even use the same sessions.
In the end, based on your limited question, sails can do what you want.
I'm making an app that will have:
iOS and Android apps
A web-based "dashboard" to display data gathered from the mobile apps
The app requires that end-users create an account with us (we mostly likely will NOT use Facebook/Twitter logins).
Everything is/will be hosted on AWS using EC2/RDS/S3 (All encapsulated in Elastic Beanstalk)
| Web Browser | <----> | sails.js app | <-------> |actionhero.js API|
⬆︎
⬆︎
| Mobile app(s) | <-------------------------------------/
So far, I've built most of the backing API in actionhero.js, hosted on AWS.
It made sense to me to separate the API and the web app, because there web app is only for a small subset of users -- I'd expect 50x the traffic from our mobile apps over the web app.. We could scale the API to server the mobile users without unnecessarily scaling the sails.js app.
My questions are:
(biuggest unknown) How should I handle authentication? The sails.js app needs to be able to make requests to the API, and so do the mobile applications.
I was looking at the oauth2orize node module for creating our own Auth server, but it is designed for Connect/Express, so I don't think I could leverage it in the actionhero.js-based API.
If the solution is to create an OAuth server, am I supposed to host that on its own EC2 instance?
(AWS-specific question) I don't fully understand the use case for creating what AWS describes as a "worker tier" enviornment. Would there be a reason that the API would fall into that category?
If I want to run a data querying and aggregation task, I would create a separate node process for that, correct? If so, would that background worker have to exist on its own EC2 instance?
Sails.js and Actionhero.js both provide heavy support for socket.io. Should communication between the Sails app and my API happen over a persistent WebSocket connection? Will that scale if I need to create new instances in the future?
This seems like a fairly typical pattern; I'd like to hear if there are any big red flags in this design, before I paint myself into a corner. :-) THANKS!
Bonus question (specific to AWS Elastic Beanstalk)
Will I create separate "Applications" for the sails.js server and the API server? It looks like that's the only way to set it up, anyhow, but I want to make sure.
We have used node and beanstalk for a couple of applications now. For authentication, you can create an account for the user when they first access the app, and store the account id on the device. If you want them to be able to log in from multiple devices, you'll need to provide some kind of way of them identifying themselves, which is either id/password, or using Facebook. It's not that tough to set that up. Use session to allow them to log in and stay logged in. We generally just store the user id in the session.
A worker tier is for something you want to decouple from your app, something that you want to do that you don't need to know whether it succeeded/failed. A notification server is a prime example. You send the info for the notification into an SQS queue, that then gets sent to the worker tier, that does the work. We are just trying to figure this out now.
A big aggregation process, yes, I'd take it elsewhere, so it's not eating up your production server(s). You might want to create some data aggregation ongoing, as transactions are saved, so it accumulates. Big rollups after the fact can be time consuming and fragile.
Sounds like yes, they would be seperate applications.
A good tip. We use grunt to create the zip files for the app. It's a node batch tool. We check the latest info out of SVN, clean it up by doing things like removing .svn directories, apply our configuration into the config files by doing simple string replacement, then zip up resulting output. This then gets loaded into beanstalk. This takes all the guess work and time out of actually doing a new deployment. We can get a new build up in minutes that way.
Beanstalk can be very frustrating. When it fails, it's not very good at telling you why.