1

I am looking to implement real-time updates in my application that has a node.js backend. I want to use socket.io for this and I understand the library that needs to be implemented. However, I already have a node.js server running:

app.listen(process.env.PORT, () => {

    console.log("Server is up and running")

})

The question is fairly simple: is it possible to use the same server with the same port to listen for socket.io connections, or should I run this entirely on a different server or just open another port for this? Because what I often see in the examples is that it listens to http. See below.

What I usually see (this example comes from this post)

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);

http.listen(3000, function () {
    console.log('listening on *:3000');
});

Now, if I would use the same server and port, how could I also listen for incoming socket.io requests or emit to its clients? Can I just keep listening with app.listen and will it also connect to socket.io?

PennyWise
  • 595
  • 2
  • 12
  • 37

1 Answers1

1

In short yes, the socket connection starts as an http request on the same address and port.

The WebSocket protocol was designed to work well with the existing Web infrastructure. As part of this design principle, the protocol specification defines that the WebSocket connection starts its life as an HTTP connection, guaranteeing full backwards compatibility with the pre-WebSocket world. The protocol switch from HTTP to WebSocket is referred to as a the WebSocket handshake.

At this point the HTTP connection breaks down and is replaced by the WebSocket connection over the same underlying TCP/IP connection. The WebSocket connection uses the same ports as HTTP (80) and HTTPS (443), by default.

https://websocket.org/aboutwebsocket.html

Dominic
  • 62,658
  • 20
  • 139
  • 163
  • Would it also be recommended? What I mean is, would it have downsizes in terms of performance etc? I have a basic application with regular GET/POST requests in node.js to retrieve data from my MySQL database. I would then use socket.io to send live updates (notifications) to users and in a later stage I would like to implement a live chat running on another database (probably MongoDB) but connecting to the same server, thus why I would like to implement both in the same infrastructure: one server to handle all my requests at the moment. – PennyWise Apr 06 '19 at 23:14
  • You can run it on a different port but it would be running as an HTTP server which would resolve connections to websocket so there would be no benefit in terms of performance if they are running on the same box, especially since they are both using NodeJS so the websocket server would be using the same underlying tech (as well as resources). – Dominic Apr 06 '19 at 23:17
  • Makes sense. When a lot of traffic comes in, I can imagine separating them into two different systems with their own allocated RAM/CPU/Memory would be optimal to improve performance. However, I am not too concerned about infrastructure in this stage (but keeping all options for further expansion open) as I first want to validate my proof of concept. Can you illustrate how I would start listening with socket.io on the same port as well? I have tried this yesterday but got an error basically because I was listening twice on the same port (app.listen and http.listen). – PennyWise Apr 06 '19 at 23:26
  • Yes a single server with the two should easily handle quite a lot of traffic before needing to scale. What you've written is already correct you don't need `app.listen` too. Under the hood `app.listen` is just creating an http server and routing traffic through `app`, it's a convenience thing. Creating the http server yourself is better as you have more control (e.g. easily swap it with an https server). – Dominic Apr 06 '19 at 23:38