I am creating a server using NodeJs and Express, but I found out that if I want to make a service live, I need to use Socket.io. In this server, there are some service that don't need to be live, and these are implemented using express routes. This are tested and correctly working. Now I have to let some services to be live. So, I think I should implement also socket.io in my server configuration. This is my code without socket.io, working perfectly:
const express = require('express');
const morgan = require('morgan');
const cors = require('cors');
const mongoose = require('mongoose');
require('dotenv').config();
const app = express();
const port = process.env.port || 5050;
app.use(morgan('dev'));
app.use(cors());
app.use(express.json());
app.use(express.urlencoded({ extended:true }));
const uri = process.env.ATLAS_URI;
mongoose.connect(uri, {useNewUrlParser:true});
const connection = mongoose.connection;
connection.once('open', () => console.log('Connected'));
const routes = require(#every routes);
app.use(routes);//all created routes
app.listen(port, () => {console.log(`Server listening on port ${port}`)});
NOw, I should import correctly socket.io. When it is done, I think I can figure out correctly hot to implement my services. So, I tryied to add the line const io = require('socket.io').listend(app) as I saw in another stackoverflow quesion, but the terminal shows up this error:
const io = require('socket.io').listend(app)
^
TypeError: require(...).listend is not a function
So, I don't know how to integrate this two. I don't know if it is worth to use the same port, or if I should use another port for the socket, but I think the same port would be good. If someone knows how to implement socket.io in my current code, or a way to keep both functionalities, please help me. Thank you so much
Change this:
app.listen(port, () => {console.log(`Server listening on port ${port}`)});
to this:
const httpServer = app.listen(port, () => {console.log(`Server listening on port ${port}`)});
Then, add this:
const { Server } = require("socket.io");
const io = new Server(httpServer );
This will let both your Express server and your socket.io server share the same http server. Since all incoming socket.io connections are identifiable with some custom headers, the socket.io code (actually the underlying webSocket transport does this) can grab those and handle them independently from your regular http requests.
See plenty of examples in the socket.io doc which has improved immensely from its early days.
Sometimes, it's easy to get confused looking at different examples because there are a dozen different ways to create your http server that you use with Express. The general idea here is that whichever way you use, just make sure you assign the http server instance that you created to a variable that you can then use with socket.io server initialization (as shown above). In your Express code, app is not the server. That's the Express app object which is also an http request handler. It's not the server. The server is something you get from http.createServer() or something that app.listen() returns to you (after calling http.createServer() internally).
Related
For educational purposes I try to deploy an Express Server that is using Socket.IO. The Server should be able to deliver a static HTML Site that was built with React, answer with a "Hello Azure!" message whenever I make a GET Rest Call to http://localhost:4000/api/azure and whenever a new client connects to the site, all the other clients get a message announcing the new client.
const path = require('path');
const express = require('express');
const app = express();
const server = require('http').createServer(app);
const io = require('socket.io')(server);
const router = require('./api/azure');
const PORT = process.env.PORT || 4000;
io.on('connection', () => {
console.log('A new user has connected!')
io.emit('broadcast', 'A new user has connected');
});
app.use(express.json());
app.use('/api/azure', router);
app.use(express.static(path.join(__dirname, 'build')));
app.use(express.static('public'));
app.use('/', (_, res) => {
res.sendFile(path.join(__dirname, 'build', 'index.html'));
});
server.listen(PORT, () => {
console.log(`Listening to http://localhost:${PORT}`);
});
All this tasks are fulfilled without problems in localhost. The problem begins after this app is uploaded to one of my Azure WebApps.
Instead of delivering the message "Hello Azure!" when I call the https://mydomain.azurewebsites.net/api/azure it responses back with the HTML file.
The typical Socket.IO GET method for polling
https://mydomain.azurewebsites.net/socket.io/?EIO=4&transport=polling&t=SomeString
responses back with the HTML file, too.
Everything url extension that I give, gives me back the HTML file.
I barely know the basic stuff about WebApps. Maybe there is a configuration that I am forgetting? By the way I haven't done anything in the configuration except that I enabled the Websockets in the WebApp config.
This never happened before. The only difference is that right now I am using a free-tier just to test. Could it be that? If not, what am I doing wrong?
Thank you for your time!
To begin with, try turning the Web Socket config off as it applies to an IIS setting which tends to contradict with the Node.js websocket implementation.
If this doesn't help, try and force the transport layer to use Websockets and SSL.
io.configure(function() {
// Force websocket
io.set('transports', ['websocket']);
// Force SSL
io.set('match origin protocol', true);
});
Also, you cannot use arbitrary ports (port 4000 in your case) on services like App Service. Your app will be provided a port via process.env.PORT. So ensure that you are refering to the correct port from your log message. You should be able to see these in your log stream.
Also note, that Azure has launched a fully managed service called Web PubSub to power your apps with Web Sockets. The app service web socket implementation does not scale horizontally, this where Web PubSub will help you.
https://azure.microsoft.com/en-in/blog/easily-build-realtime-apps-with-websockets-and-azure-web-pubsub-now-in-preview/
I'm building a VueJS app using vue-cli's webpack template.
I've split the front and back ends into different Heroku applications and deployed them.
Background:
My client app has the same setup as described here
tl;dr the above Medium article:
We now have a fresh Vue-cli/webpack app, and a server.js file used to create an Express server that serves the built app files.
The problem:
I've been running into issues trying to use socket.io on said server.js file.
Here's how server.js looks like:
var http = require('http'),
path = require('path'),
express = require('express'),
app = express(),
server = http.createServer(app),
socketIO = require('socket.io'),
port = process.env.PORT || 8080,
history = require('connect-history-api-fallback'),
serveStatic = require('serve-static')
app.use(serveStatic(path.join(__dirname, '/dist')))
server.listen(port, () => {
// logs when running node server.js
console.log('listening on port', port)
})
const io = socketIO(server);
io.on('connection', (socket) => {
console.log('Connected!!!');
});
And this is how I call socket.io inside of my .vue component:
const io = require('socket.io-client')
const socket = io('http://localhost:8080')
As soon as this last line is uncommented I receive a friendly Failed to load resource: the server responded with a status of 404 (Not Found) http://localhost:8080/socket.io/?EIO=3&transport=polling&t=M9yJX8nsocket.io/?EIO=3&transport=polling&t=M9yHe0F
Additional info:
Not sure if relevant, but still saying - I'm Using "connect-history-api-fallback" to point all non-existent routes to a wildcard 404 .vue component that displays a friendly user message and allows them to go back to existing routes.
Can this be a part of the reason? What I read about my issue is that I probably have trouble making socket.io run on the same server that my app is running in.
I experienced the problem initially when trying to first connect my Vue App with Vue-Socket.io
upon the line
Vue.use(VueSocketio, socketio('http://socketserver.com:1923'));
Where as an URL I used http://localhost:8080
I've spend a good few days on the problem and still have no clarity on where this problem is rooted in. I am really trying to understand and would highly appreciate any form of feedback. I read about people having the same / similar problem, and tried calling io() without my localhost + port url.
First question here, hope it's properly asked.
Okay, guys, I don't know why, but following the code placed in the "Docs" section of Socket IO's website resulted in the same error (Express 3/4 section). I then went on to copy the Chat demo and had success, so I'm now importing Socket.IO in my Index.html file
<script src="/socket.io/socket.io.js"></script>
<script>
var socket = io();
</script>
With server.js looking like this:
var path = require('path'),
app = require('express')(),
http = require('http').Server(app),
io = require('socket.io')(http),
port = process.env.PORT || 8080,
history = require('connect-history-api-fallback'),
serveStatic = require('serve-static')
app.use(serveStatic(path.join(__dirname, '/dist')))
http.listen(port, () => {
console.log('listening on port', port)
})
io.on('connection', (socket) => {
console.log('Connected!!!');
});
I'm going to close this now and see how to implement the functionality I'm looking for - I now have a good starting point. Best of luck to anyone struggling with this.
Cheers!
On another terminal,
$curl localhost:3001
However, on nodejs server side,
I never saw
"sdfsdf" for
console.log("sdfsdf");
Questions
1 Can some expert explain why?
2 How to fix it to make 'connect' callback triggered?
Thank you.
var express = require('express'),
http = require('http')
var app = express();
var server = http.createServer(app);
//var server = http.Server(app);
//server.listen(app.get('port'), function () {
server.listen(3001, function () {
//logger.info('openHAB-cloud: express server listening on port ' + app.get('port'));
console.log("3001");
});
app.get('/', function(req, res){
//res.sendfile('index.html');
res.send("xxx");
});
io = require('socket.io').listen(server);
io.on('connection', function(socket) {
console.log("sdfsdf");
});
To connect to a socket.io server, you must use a socket.io client - you cannot just use a regular curl or http request.
A socket.io client must be specifically designed to connect to a socket.io server. That means it uses the socket.io message format on top of webSocket and it follows the proper convention that socket.io and webSocket use for connecting.
Here are some client-side examples: https://socket.io/docs/client-api/
The connection can be made either from browser Javascript with the appropriate socket.io library included or using any socket.io client-side library from some other Javascript environment.
To see a bit how webSocket connections (which socket.io uses), you may want to read this: How does WebSockets server architecture work?. And then, socket.io adds its own message layer on top of webSockets.
const io = require('socket.io-client');
const socket = io('http://localhost:3001');
I have recently inherited a project of a Node.JS and Express based API, and I have noticed express server creation is as such (simplified version):
// http is required.
var http = require('http');
var express = require('express');
var app = express();
// Note http is used to create server, and app is used as param:
http.createServer(app).listen(3000, function (request, response) {
console.log('listening on port 3000');
});
Everything works as expected of course.
I have been trying to figure out what exactly is happening behind the scenes here, mostly in comparison to the method in Express API, which shows:
// http is not required.
var express = require('express');
var app = express();
// Note Express is used to create the server:
var server = app.listen(3000, function () {
console.log('listening on port 3000');
})
Note the difference in server creation using http, and using Express directly.
Is there any benefit in using a specific one of the two method? What is the actual difference between the two?
Micro-optimization-wise, is it preferred to avoid requiring 'http', which is probably required by express anyway?
Thanks from ahead!
Both are more or less functionally equivalent, in the second example the express constructor returns a new object which effectively wraps up the http.createServer call internally (i.e. when you call app.listen).
If you are going to use express then you should use it's recommended APIs, the first approach is considered outdated.
Using node and express, the below works just fine.
var app = express();
app.listen(app.get('port'), function() {
});
I assume that a server is created implicitly in the above construct.
When adding socket.io, I've seen the following being done.
var app = express();
var server = http.createServer(app);
var io = require('socket.io').listen(server);
app.listen(app.get('port'), function() {
});
What is the need for explicitly adding http.createServer(app) ? Won't the creation of an additional server mess up things ? Or put it other way, is it ok to create many more http.createServer(app) ?
In either case, only one server is created. When using socket.io, you share the same http server between socket.io and express. Both libraries attach event listeners to the same server and have a chance to respond to the same events. They cooperate nicely because socket.io only handles relevant requests and express handles all the non-websocket requests. And just FYI you could not create more than one server on the same port. Only one process can listen on a TCP port at a time in the OS, so the second one would fail with an error when attempting to bind an in-use port.