I have gone through different blog articles to find out how a full-fledged application can be modeled and developed with React,Redux (working on front-end) with API end-points communicating with an ExpressJS server.
To my knowledge, we need to have:
a). One expressJS application developed with all possible end-points (available for an API access). This application should be running on a port e.g. 7070. This server side application will be communicating with the database.
b). Develop a React, Redux based application for front-end and run this application on a different port e.g. 8080 using webpack, gulp or grunt server.
I am sure this is not the only model. Or, maybe my concept is little weak. But this post will clarify concepts globally to all Frontend+fullstack developers. Please write your recommendations and expert opinions on followings:
Is my defined model right?
Is there a way, or possible to use ExpressJS application to throw a ReactJS application as one-page application (which process and render all defined React routes on client side).
/* a reference example of using root route handler in Express to throw an
index file (which includes bundle.js react application), this works okay,
but can not handle or render React Routes on client side; and instead
if a menu link clicked that sends request to Express but Express
application file only had '/' route to handle.
*/
app.get("/", function(req, res){
res.sendFile(dirname + "index.html"); // but this is not viable
})
If point#2 is possible then our application can run on same port right? And our application can also use Express routes as an API end-points. But I'm sure that will not be the recommended way or even possible; unless we do the server side rendering of React (in our server side ExpressJS application).
Deployment
Scenario: React+Redux+Express+DB (mongoDb, Redis, MySql or Postgres etc.) Full Stack application
Online/Cloud Hosting
Normally we are hosting our application on any 3rd party server (or cloud server). The normal shared hosting does not work unless they have NodeJS server. Most common are: Heroku, AWS, RedHat OpenShift, Nodejitsu, Microsoft Azure, Modulus, Firebase, etc.
In this case most of the server side things are easy to setup and headache free.
Local Network (Internal Company/Corporate Server) Hosting
i). Linux Bases server (any version) + SSL installed + Required DB Installation + NodeJS installation + Dedicated IP
ii). Windows Bases Server + SSL installed + Required DB Installation + NodeJS installation + Dedicated IP
Can anyone elaborate more on the internal server hosting setup procedure with all security measures in more details? I really do not know what each step that should be taken would be.
It will also be helpful if any technical person could write about application modeling as well. This will help everyone.
Note: The answers should be short in the question context (not in the question subject line context, which is quite broad). Any reference or links will be good to make answer quite short.
Related
I am lost in the difference between web server and application server but as i could understand that web server serves a static content while application server used in case of large scale traffic to manage data!
So, can i consider Apollo server for example an application server as it can receive client queries and retrieve data from a database and manipulate it?
I know this question may make no sense for backend experts, but i am a frontend developer who try to grasp some backend concepts
Can I / Should I host Angular, Node-express and Mongo on same server, say localhost:3000 or somehosting.com/server-address?
Also is it a good practice?
I've seen Angular and Node running on same server, but what about adding mongo too?
like everything equivalent to
mongodb://localhost:3000/db
ng serve --port 3000
server listen(3000)
Thanks
As you have not mentioned for what purpose - the answer will be depending on the purpose and context. If you are learning, then running webserver, database and serving Angular static files , all from the same server is not an issue. However, if you are going to have live web app, even with less or moderate traffic, then you must run database on its own server, and the webserver and static Angular files from one server. Of course, for SPAs that expect lot of traffic and real use, it is better to serve your static Angular files from a CDN or storage service like AWS S3, and web and database servers separately.
Happy learning!
It is best practice to keep the databases(stateful) in different servers then the applications(stateless) unless it is just for testing...
I just starting to learn MERN Stack development as a former .Net developer. I wanted to develop my skills in this area and after lots of researching I just can't figure it out why we need to have two different running port/app when we working with react js?
Firstly I have developed some simple application by using NodeJS, Express, EJS View Engine and already deploy it to Heroku. So far, this works fine for me. I can develop all my personel site with those technologies including MonoDb later. But to become complete MERN Stack developer I started to search React and realized that it only works with giving another port to seperate it like client application. Why we can't use react and all other things in under one port?
This confused me when I get two different web page under;
http://localhost:5000/ (React App)
http://localhost:3000/ (Server Side: opens different html given by me using EJS)
Apperantly if we give same port number with server (3000) in react's package.json file then it gives following warning;
Something is already running on port 3000.
npm run client exited with code 0
Is it due to nature of ReactJS?
You totally can run React and Node on a single port - but it doesn't make for an efficient workflow.
The core answer to your question lies in separating front-end routing from back-end routing. When using React Router your application manages the UI based on the URL parameters.
i.e
http://localhost:3000/some-ui-path
At the same time when using Node as a back-end to respond to HTTP requests - you send the requests to specific URL paths.
i.e
http://localhost:3000/some-api-path
Separating the ports easily lets you differentiate between which route should be handled by React Router on the front-end and which route should be directed to the Node on the back-end.
http://localhost:3000/some-ui-path = React Route
http://localhost:9000/some-api-path = Node HTTP Route
In your configuration files you can customize your front and back end setups so that any request to a certain path will be redirected to your node server.
An Example:you can define that any path prefixed with /api/ should be proxied to port 9000:
http://localhost:3000/api/some-api-path ==> http://localhost:9000/some-api-path
You can use whichever ports you like but 3000 5000 and 9000 are common defaults used by starter kits and module bundlers like create-react-app and webpack
Hope this helps, let me know if I can explain further!
You cannot run React and Node.js server in a single port.
Why?
React uses webpack to bundle all the component files into a
single JS file. This JS file is then served by a
webpack-dev-server which is a part of webpack.
This webpack-dev-server is needed only during development. In production, you use npm run build or yarn build to bundle everything into a directory called build which will be served as a static asset by your Node.js server.
So, during development, you need to use two different ports for:
webpack-dev-server: This by default runs on 3000. If you try to run your Node.js server, you'll get an error.
Node.js server: This should run on port other than 3000.
Note: webpack is used as a default module bundler when creating React app using create-react-app.
Let's start from the port. Port is a logical construct that identifies a specific process or a type of network service. Port is a communication endpoint. And you have two different services, so it seems logical to use different ports generally. Your question is really good. I'm waiting for new answers.
Also a .Net developer here! I had the exact same question around myself and this article seems to clarify a little for me.
It seems like you need two servers (two ports) for development only. In production, you will only have an API server running, with some endpoints simply serving static files in /build directory like:
app.get('/', (req, res) => {
res.sendFile(path.join(__dirname, 'build', 'index.html'))
})
I think the reason why we run two servers (one react webpack server and one API server) ports in development is because 1) we don't want to run npm build every time you make a change and 2) because of not needing to build every time you make changes, it allows hot-reloading for fast development.
I have got 2 applications:
Nodejs application and Angular application.
I would like to host them both on the same Linux server (Linode).
Also I have a DNS record for example : forexample.com.
I would like that when I navigate to api.forexample.com it will navigate inside the linux server to the Angular application, and I should see the angular pages.
The nodejs application is a API application which I would like other people to make all the HTTP requests to api.forexample.com/api.
So the question is how to make the navigation inside the linux server?
Generally speaking to run multiple applications on a server. First you need to add an A record on your DNS record for api.forexample.com
Then you can use nginx to handle the two applications. The way it will work is that each application will run locally on its own port and nginx will handle the url you provide and map it to the appropriate application. Check out this tutorial: Configure Nginx as a web server
In your situation you could serve the angular app from the node application.
Check this too: How to serve an angular2 app in a node.js server
I want to ask about some good practices. I have a Node.js (Express) web server and socket.io push server (in case technology matters). I can turn both of them into one application but I want them separated (they can communicate with each other if necessary). There are two reasons to do that:
It will be easier to manage, debug and develop the app;
It will be a lot easier to scale the app. I can just add another instance of push server or web server if necessary;
This is at least what I believe. The only problem is that when a client connects to the seperate socket.io server then it won't send cookies (different port, cross-domain policy).
The workaround I came up with is to put a reverse proxy (written in Node.js as well) in front and check what kind of request we are dealing with and send it to web server or push server accordingly. Great, now we have cookies in both web server and push server. The reverse proxy can be a load balancer which is an additional bonus.
It looks like a good idea to me. What do you think about this design? Perhaps any other workaround for cookie problem?
I recently did something simular, we initially used a node.js reverse proxy but ran into reliability/scalability problems. We found serving static files and proxying requests was best left to nginx. haproxy is also a very viable solution for stand alone proxying as well.
HaProxy
Nginix as a reverse proxy