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?
I've got a system running mainly PHP for server-sided logic, however, I am using Node.js for a few parts of the system and I've got a question about what the best way to handle this is.
The Node.js server is used solely as a websocket server. I'm using Socket.IO as the API for the sockets.
Currently I have three different uses for the sockets, i.e. A queue to handle incoming requests, a chat server and an announcements system.
My question is; is this the best approach? The file looks messy, all my logic is in the single file. Should I spread this out to separate files to handle each part, OR, should I be creating multiple socket servers to handle the different uses?
With this current implementation, i'm finding it very hard to debug any failures, as there seems to be too much happening in the one script.
Any help would be appreciated,
Thanks!
I think this is down to preference and the size of your system.
Personally I would at least separate the logic for each component into separate modules. That way at least each bit is kind of self contained and the system can become modular. In my opinion this makes it far easier to maintain and add/remove components.
Running multiple socket servers could be a bit overkill if your app is small, however if your having trouble separating the data to be handled by each part it could be worth considering running more than one.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 months ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
In what cases should one prefer to use Node.js only as a server in real deployment?
When one does not want to use Node.js only, what plays better with Node.js? Apache or Nginx?
There are several good reasons to stick another webserver in front of Node.js:
Not having to worry about privileges/setuid for the Node.js process. Only root can bind to port 80 typically. If you let nginx/Apache worry about starting as root, binding to port 80, and then relinquishing its root privileges, it means your Node app doesn't have to worry about it.
Serving static files like images, css, js, and html. Node may be less efficient compared to using a proper static file web server (Node may also be faster in select scenarios, but this is unlikely to be the norm). On top of files serving more efficiently, you won't have to worry about handling eTags or cache control headers the way you would if you were servings things out of Node. Some frameworks may handle this for you, but you would want to be sure. Regardless, still probably slower.
As Matt Sergeant mentioned in his answer, you can more easily display meaningful error pages or fall back onto a static site if your node service crashes. Otherwise users may just get a timed out connection.
Running another web server in front of Node may help to mitigate security flaws and DoS attacks against Node. For a real-world example, CVE-2013-4450 is prevented by running something like Nginx in front of Node.
I'll caveat the second bullet point by saying you should probably be serving your static files via a CDN, or from behind a caching server like Varnish. If you're doing this it doesn't really matter if the origin is Node or Nginx or Apache.
Caveat with nginx specifically: if you're using websockets, make sure to use a recent version of nginx (>= 1.3.13), since it only just added support for upgrading a connection to use websockets.
Just to add one more reason to pauljz's answer, I use a front end server so that it can serve up 502 error pages when I'm restarting the backend server or it crashes for some reason. This allows your users to never get an error about unable to establish a connection.
It is my belief that using Node to serve static files is fine in all circumstances as long as you know what you're doing. It is certainly a new paradigm to use the application server to serve static files as so many (every?) competing technologies (PHP, Ruby, Python, etc) require a web server like HTTPD or Nginx in front of the application server(s).
Every objective reason I have ever read against serving static files with Node revolves around the idea of using what you know best or using what is perceived as better-tested / more stable. These are very valid reasons practically speaking, but have little purely technical relevance.
Unless you find a feature that is possible with a classic web server that is not possible with Node (and I doubt you will), choose what you know best or what you'd prefer to work with as either approach is fine.
As for Nginx vs Apache -- they will "play" with Node the same. You should compare them without regard to Node.
Using Node.js only
Node.js can do all the tasks of a web server: serve static files, respond to an API call, run server on HTTPS... There are also a lot of packages that provide extra functionalities like logging the request, compress the response, set cookies, prevent XSS attacks... Lack of functionalities isn't likely a reason for using another Webserver (Apache/Nginx/etc..) to complete Node.js. In other words, for a simple application that does not need to scale, you don't need to add an extra layer to Node.js, it just complicates the problem.
Using Node.js with another webserver
Each web server has its own advantages. For example, Apache allows additional configuration per-directory via the .htaccess file. Nginx is known for its performance when it comes to serving static files or acting as an reverse proxy. Node.js provides a huge benefit when dealing with I/O heavy systems... Sometimes, we need to combine the forces of different web servers to satisfy the system's requirements.
Example: For an enterprise-level application that might scale up in the future, set up Nginx as a reverse proxy before Node.js application has some advantages :
Nginx can act as a load balancer to dispatch traffic to your NodeJS instances if you have more than 1.
Nginx can handle HTTPS, caching, and compression for you. Encryption and compression are heavily computed operations that NodeJS is not good at. So using Nginx will give you better performance.
Nginx will serve static content, which reduces the load of Node.js.
Separation of concerns: Nginx takes care of all the "configuration" part, and Node.js focus on the application logic.
Placing NGINX in front of Node helps better handle high connection volumes. NGINX offers (to name a few) caching, load balancing, rate limiting (using the leaky bucket algorithm) and can help mitigate attacks if paired with a banning service like Fail2ban.
As for production applications, you can run your application server behind NGINX as reverse proxy, coupled with a caching server like Redis- all of which can be situated behind a content delivery network as another line of defense from exposing your ipv4/ipv6.
An extra: It is important also if you need a Reverse Proxy, for example to execute a Websocket Server on the same port, or maybe mix some techonlogies (reply with NodeJS some requests and with PHP some others or whatever)
My question is rather straightforward. I started developing quite a large project and realized that node.js COULD be a viable solution. Since I am still new to node and therefore not in the position to determine if it's the right thing for me, I decided to ask here.
The project: It's basically an administration solution for gameserver providers. It includes both a web administration panel as well as server components to control everything.
My doubts are if I should use node for the panel.
It will require life updating of data (where sockets could come in handy) and we plan on developing it as a "one-page" kind of app.
Having it node means it would be able to perform tasks asynchronously and on it's own (instead of, say, php and cronjobs)
It will be distributed. Making it node would make this easy. No dependencies besides node, and a simple "npm install".
It will have multiple people connecting to it and using it at the same time.
Will node be able to handle these multiple connections well? Performance wise, will it be a good choice?
Will node (and maybe Derby) suffice to build a good web panel?
Am I right about any of the points I made, or did I miss something?
Thanks for the help!
Sincerely
-Antariano
Well you did answer yourself for some of the questions. Thanks to the asynchronous tasks node can take quite a load of connections so it should handle your app. I don't know Derby, but express is also good for your task.
Also when one node server will be insufficient you can always deploy next one and just create some communication between them. Since node is lightweight it can do the job.
Will node be able to handle these multiple connections well?
Yes.
Performance wise, will it be a good choice?
Yes.
Will node (and maybe Derby) suffice to build a good web panel?
Yes.
Am I right about any of the points
You are right with all of them.
I think node will be sufficient for this job.
Are there any examples or conventions out there of how to use node.js to host multiple web apps?
I'm already aware that node itself can be used to build a server, but I'm curious as to whether there have been implementations where you aren't necessarily running it all the time. Strictly for the reason that perhaps there are multiple sites being hosted, each with their own copy of a framework, static files and custom functionality.
Or maybe you do run one instance of node and code a multiple site architecture to ensure one bad site doesn't take the server downin some way?
Virtual hosts, ensuring that one site can't crash others...these are all things that have been considered with other platforms, but I have had some difficulties finding for node! :)
I am already aware of connect, express and other middleware, however it doesn't cover what I'm asking here.
If you're worried about runtime isolation, each "site" should run it's own node process. Then use a proxy like node-http-proxy that will do host header based routing. Another great node based option is bouncy, but you don't necessarily need to use node to do the host based routing. You could just as well use haproxy, nginx, etc.
The baseline RAM overhead of each node process is very small (~10mb - 15mb). Also, if you do HTTP based routing you can spread your sites easily across machines, user home directories, etc.
If you want to handle the site/host registration programmatically, I would use seaport and then communicate the hostname and host + port details back to the proxy so that the routing table can by dynamic. This would also make it fairly easy to scale a site across multiple node processes.
Good luck!