I've been learning Node.js for a couple of weeks. These days I was looking for advice on best practices and came across the concept of "Separation of concerns". I understood (tell me if I'm wrong) that it consists on split the backend and the frontend into two different servers. I've been using template engines such as ejs and pug so far, but I always have these files in the same directory as the rest of the Express server (in a "views" folder). I think there are many ways to separate the frontend and backend, maybe having 2 folders, 1 for the frontend with just simple HTML, CSS, and js files and make AJAX requests to the API, that will be in the other folder, the backend's one.
I'm pretty new in the backend so I hope this question makes sense haha. I'm a bit confused about how backend and frontend connections should work and how I can make a frontend that is independent of the technology used in the backend, so if you know books or resources in general about this, tell me.
welcome to stack
Best practices are different from developer to another and they are tend to be evolving.. so that is what i’m doing :
1 - Separate Directory for fronted and backendusing node proxy .
2- src Folder that contains ( for backend ) views , routes and controllers … etc .
Separation of concerns is the idea that each module or layer in an application should only be responsible for one thing and should not contain code that deals with other things.
Separating concerns reduces code complexity by breaking a large application down into many smaller units of encapsulated functionality.
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 have seen various questions here and answers on the web, but still I can't get an understanding of what's the best way to use react and nodejs/express together, where I use node to serve json content and in general to do tasks such as managing access to services for which i am Oauth-ed. I realize I am probably not grasping something very basic.
I tried (starting from create-react-app) and ended up with two different applications, server and client served on different ports and that's not what I want: besides all CORS issues, it does seem to make sense to share code.
what's the best way to do this? is it to have one or two different applications (on different ports), or how to have a single application serving sometimes json and sometimes react web pages?
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.
Evaluating Nodejs and trying to see if it will fit our needs. Coming from a rails world, I have a few unanswered questions despite searching for a long time.
Whats the best way to manage assets with Nodejs (Expressjs)? In rails, the static assets are a) fingerprinted for caching forever b) js and css are minified 3) scss is compiled down to css
Whats the best way to handled uploaded images from users such as avatars?
Does grunt help with minifying and gzipping html/css/javascript?
How can I avoid mutliple http requests to the server with Node. I don't want to make multiple http requests for every javascript asset I need. Rails helps here by combining all js and css files.
Also, is Mongodb the preferred solution for most projects? I hear a lot of bad things about Mongodb and good things about it. Having a difficult time deciding if Mongo can help with more reads than writes with probably 400-500 GB data in the long run.
Any help or pointers? Thanks so much for taking the time to point me to the right places.
For each of the point you mentioned I give you a few module examples that might fit your need. Remember that at every point there are much more modules serving the same purpose:
node-static (as a static file server), node-uglify (for minifying JS code), css-clean (same for CSS), merge-js, sqwish, and jake can help you with the building of the website (in this step you could plug-in the previous modules)
node-formidable is pretty famous
check out this question
checkout this question
I am not sure if it is the "preferred". It is the noSQL and the Javascript nature in it that makes it attractive. There are modules already for every type of database. ongo should handle that data. Depends also how large is one document. There are some limitations.
There is this Github Wiki page in the NodeJS project listing and categorizing many of the important modules out there.
The exact choice of modules also depends what framework will you use use to build the app. A pretty established (but certainly not the only one) is express. But you can find more on this topic here.