We want the front end to be completely decoupled from the backend with REST API connecting them. In that case, the front end is just html/js/css. In that case, how do you deploy the front end?
Most CI tools assume that we want to deploy a node.js application or something similar, which is not really what we are looking for? I guess in theory we can setup something like apache and deploy there?
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....!!!
I am working on a learning project. I have build an authentication system in nodejs using local and Google strategy. Front end is a react app. There are two options for hosting
Deploy front end on static hosting providers like netlify or github pages and backend node app to heroku.
Deploy both backend and front end on heroku with front end code in the public folder and use express.static('public')
I am confused about both these approaches and could not find the answer on the internet. It will be a lot of help if you can explain the pros and cons of both the method and which one is suitable in what conditions. Links to the articles are also appreciated. Thank you in advance.
First approach
Pros:
Static content served from a different server has more optimization potential (using S3/CloudFront edge caching), nginx is blazingly fast for serving static files
Less network traffic on one server (content can be served from multiple points in parallel)
The nodejs application doesn't have to "waste" time serving static files that never change as has more time for actual dynamic content
Cons
Needs more configuration, since it's running on a different origin (dealing with CORS, appropriate security settings)
Premature optimization
More maintenance
Second approach
Pros:
Easier to deploy
Fast enough in most cases
I can give you an example based on the company I work for. We separate back and front on different servers for security and convenience. We block all ip's from making requests to our backend and only release the ip of the front server. We create specific rules for each server separately and if one of the servers stops for any reason, it does not affect the other one.
But this decision depends a lot on the type of application you develop and also the structure you need for your project. But consider the following: security, maintainability, and convenience.
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.
I'm trying to build a website myself but I also want to build a native mobile application that will access the same DB in the future.
What I'm thinking now is using Node.js to build Web Services wrapper for the DB and every DB operation will be executed via web service API. And for the website framework, I'm going to use Rails.
Please let me know whether this is a good architecture or not. I'm not sure whether encapsulate data with Web Services is a good idea. Will there be any performance issue? And if it's feasible, which DB should I use? And can rails communicate with DB via web services?
Thanks a lot!
Update
Why do people down vote this question??
I think you have more technology than needed in your architecture right now.
Personally I would create a REST api on top of the DB (using either node or Rails - both are super easy to do this with and both can use pretty well any db)
Then you can write any number of "apps" for the front end process, whether they are web apps, ios apps, android apps, etc... They will all get their data from your REST api on the backend.
You might even consider writing the front end as a single page app using Angular, Knockout or Backbone, something like that. If you do that with node, your entire stack will essentially be written in javascript. It can get confusing for a newb, but it's super powerful.