Setting up a nodejs server to serve the REST interface (with json objects) to my application.
This works fine.
Currently I run Jekyll service to provide the content pages. This causes some cross site scripting issues as they are running on different ports. I can get around this but it does not seem like the optimal solution.
Is it normal to run a nodejs server to provide the REST interface and the web content interface on the same port. I have been looking at nodejs/express/Swig as a replacement for the Jekyll service but I it seems that running the express/Swig on nodejs will alter the behavior of my response objects that makes using REST not quite as optimal.
Is it normal to run a nodejs server to provide the REST interface and the web content interface on the same port
Yes, this is pretty common as it is much simpler to deal with, so many small apps/apis opt for this approach. Sometimes the API uses a URL path prefix like '/api' as a basic distinction. Sometimes folks use content negotiation where '/user/42' will send either HTML or JSON depending on the request `Accept' header.
However, it is also common to use a web server on port 80 that routes to different back end apps based on a path, so for example anything to /api would be reverse proxied to an express app on 127.0.0.1:3000 but everything else looking for content pages might go to a jekyll app on 127.0.0.1:3001.
How I would roll. Because I am very much in favor of using a real web server on port 80
nginx on port 80 reverse proxying to express for API and jekyll for content
Also possible
express listens on 80, handles API directly, uses node-http-proxy to reverse proxy content from the jekyll app
there are a bunch of other combinations you could make work easily. Mostly it's about what you think is easy to understand and is reliable, secure, etc.
Related
So I'm building an end to end application (With node.js/mysql back end, react front end, and using the express router), but I'm having trouble setting up a local development server. I don't need it to be accessed from the outside world, just be able to load different pages connecting to the express router. I don't have any dev ops experience for this, so I'm trying to use nginx to point it to the router which I can't figure out. Is there an easier way to do this?
I also need to run this on a windows machine, which just makes everything slightly more complicated
It's not entirely clear from your description how your application is set up and what the role of Nginx is.
So I'll start from the beginning...
Nginx is primarily an HTTP server which can also function as a proxy for HTTP requests. If you've written a Node.js application using Express, you have written an HTTP server which can handle any routes you have set up and can also serve your static assets (ie. HTML pages, images, front-end Javascript, CSS, etc.). In this case, there is no need for Nginx - if you wrote something like the Express "Hello World" app, then you will see a message like "Example app listening on port 3000" and you can connect to your app by visiting http://localhost:3000 in your browser.
That's it - there's literally nothing else to your app and there is no need for Nginx (or any other HTTP server) to run your application.
Now that's not to say that there is no role for Nginx in your application, but it may not be as an HTTP server. One possibility is that you may want to set up Nginx as a proxy, to handle certain routes by sending the requests to your Node application. For example, I set up an application some time ago which uses Nginx to proxy API routes for my application to a Node application and to serve static assets directly. This may be what you have in mind - if it is, you will need to configure different routes in Nginx to serve different things (and unfortunately there's not enough information in your question to give suggestions on this).
As an aside, you're probably going to find this much easier to set up using Linux - perhaps the Windows Linux Subsystem, a virtual machine running Linux, or Docker.
You'll probably want to use
https://github.com/facebook/create-react-app
create-react-app my-app will set up everything you need (webpack, etc.), and then
npm start will start a local development server.
Should work on Windows, but I don't know, because I wouldn't use/recommend Windows ;-)
I never done any API, I just recently become aware of REST, never used sockets or node.js, but I have this simple project in mind using all of these.
Imagine usual app with request/response stuff. Nothing fancy. But then sometimes I need real time functionality, lets say there's a live support for website, a chat. So majority of users never need sockets and everything is easy, but when they do, what's then? How that would look and work with restful api?
As you tag, socket.io is perfect for you. It creates a socket within the browser to your server without the user installing any third party program, using websockets and longpolling. And for the users that have old browsers and don't have those browser built-in functions, it can fallback to a third party plugin: Flash Player, but almost all browsers have it installed.
Is you are used to Javascript or object oriented programming, socket.io and node.js is a walk in the park. If you don't want to use node.js and socket.io, you can write your own implementation of client-server with this info:
WebSockets
Long Polling example
Flash AS3 Socket
As a small adition, simply you need your default web server (Apache, Nginx, Lighthttpd, whatever...) running in default port 80 and also running a node.js server in other port, let's say 8080. That second server will serve all the files needed to connect, because socket.io can only connect to the same domain and port that served the files (security reasons, I guess).
In short, you'll have 2 servers: One serving your entire webpage and another one serving the files needed to connect to your chat (and also serving the chat, obviously).
I have exactly that configuration made in one of my pages (a live sports streaming site) and to add the chat to my site I have this server running in port 8080 and I load it in the main page inside an iframe: http://www.example.com:8080/
As an adition, you can create a complete http server in node.js, but I don't guess that it is useful as a professional web server.
I'm creating a new SPA web application in order to learn Node.js.
I want to use Node.js purely as a fast API to pass JSON data to and from the server. The front-end will handle all UI/templating etc.
The issue I have is that the Node api will listen on a different port to the front-end which means cross-domain ajax calls. I don't really want to use jsonp as it's a bit of a hack and all requests would have to be GET requests. I don't want the front-end to be on the same port as the Node api either as www.mywebsite.com:9090 is not a nice web address.
Is there a common way overcoming this different port issue so that my site on port 80 can make normal json ajax requests to the Node api (which as I understand it cannot run on port 80)? It will be hosted on Azure or similar, not sure if that makes a difference.
Thanks
Please pardon my ignorance on node.js. I have started reading on node.js and have some perception which might be wrong. So needed it to clarify
When we use createServer() method, does it creates a virtual server. Not sure whether the term "virtual" is appropriate, but it's the best I can describe it :)
I am confused that how should I deploy my application having node.js + other custom js files as a part of it. If I deploy my application in the main server, does that mean I have two servers?
Thanks for bearing with me.
I will try to answer that:
Q1:
createServer basically creates a process which listens on the specified port for the requests. So yes you can call it as a virtual server which constantly listens for request at the port.
Q2:
Yes you can say that it has now 2 servers
For eg: you server had apache initially which listens to port 80 (you can access it as http://example.com/ it by default looks for port 80)
and then you also start the node service listening on some other port for eg: port 8456 (you can access it as http://example.com:8456/ which will look for port 8456)
So yes you can there are two servers.
EDIT
Q: So what would be the difference if the page is served by the physical server and the virtual server created by node.js?
Physical Server and Node Server are 2 different things and there is no way a single request is going to both the servers.
For eg:
I use apache server to host my website running on PHP. It serves all the html contents of my website (which involves connecting to mysql for data).
Some of the requests could be:
http://example.com/reports.php
http://example.com/search.php
At the other end I might be using nodejs server for totally another purpose. For eg: I might use it for an API, which returns JSON/XML in return. I can use this API myself for some dynamic contents by making AJAX calls with javascript or simple CURL commands from PHP. Or I might also make this API available to public.
Some of the requests could be:
http://example.com:8456/getList?apikey=¶m1=¶m2=
My choice for NodeJs Server used as an API would be for its ability to handle concurrent request and since its asynchronous for file operations it will be much faster than PHP.
In this case I have a website which is not only working on PHP but its the combination of 2 different technologies (PHP on Apache and Nodejs) and hence 2 servers are totally different running on same server but have there own execution space.
Third Question:
So what would be the difference if the page is served by the physical server and the virtual server created by node.js?
If I might add, it's a virtual server in the sense that apache is an virtual http server listening on whatever port. Of course apache had a lot more modules and plugins and configurations to it where as Node's is lighter (kind of like WEBrick for rails), non-blocking and agile for building on. Then again apache is more stable.. in other words, it's a decision of software, both sitting on the server listening to a particular port set by you.
That said there's deployment methods that allow you to place a node application in front of software such as nginx (another server-side software) or HAproxy (load handling with a lot of power), so really it's all up to how you choose to configure it.
Maybe I'm getting to far from your question, but I hope this helps!
Also, You should give the answer to the other guy, he came first ;)
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