I'm new to Node.js and built my first app helloworld.js. I know java and tomcat architecture well. But I have some questions:
I wonder how to create a second web-app that always responds on the
same port but with different url.
For example
http://localhost:3000/
http://localhost:3000/app1/
http://localhost:3000/app2/
I saw that there are different ways to access the various db. In the
node js world there is something like hibernate that makes the dbms
transparent to the programmer?
There is something like tiles and tag library to build html page?
In order:
Unless you use nginx or some other reverse proxy, that is not possible. However, you can run different applications on different ports like 3001, 3002 etc, and run a server which acts as an intermediary between your client and these servers at port 3000.
Depends on framework to framework.
I am not familiar with tiles and tag, but in nodejs land, you can use ejs, handlebars or jade to design templates.
Related
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.
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.
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.
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 ;)