The application, an API server meant to communicate with a Unity client was working just fine, until I added sockets. Manually testing socket.io using the chrome extension socket.io tester demonstrated that it is working just great on my local machine. Now that I've deployed it to heroku, it doesn't work. It crashes right off.
Typically, answers to this issue are all about the PORT not being set correctly, but in this case I have set the port to process.env.PORT, so there shouldn't be any problems with that. My app was working just fine until I added socket.io.
Here is my basic server file:
import express from "express"
import mongoose from "mongoose"
import http from "http"
import config from "./config/index.js"
mongoose.Promise = global.Promise
// mongo
mongoose.connect(config.mongo.uri)
mongoose.connection.on("error", function(err) {
console.error("MongoDB services error: " + err)
})
// server
let app = express()
let server = http.createServer(app)
let socketio = require("socket.io")(server)
require("./socketio").default(socketio)
require("./express").default(app)
require("./api").default(app)
// start
server.listen(config.port, function () {
console.log("Listening on port: " + config.port)
})
export default app
Is there anything here to imply why the app may be crashing?
So for anyone who might also be having trouble with Heroku in this way. It turns out that I had my config file with the proper port setting listed in my .gitignore file. (I don't know how it got there!) I wasn't paying attention to the logs when the app was starting up so I was missing the log that it the config file was missing. I was impressed by how Heroku's staff was able to point that out.
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 have built a project in Angular 9 for the frontend and Node.js as the backend server.
Now I am running node appserver.js for running the backend server. This listens to port 9090 as default. In another terminal, I am running ng serve to run my Angular app on port 4200 as usual. I have a service in the Angular app that sends and receives messages from server.
I have used WebSocket class to connect to the port 9090. My app works fine in local. But now how could I deploy in Heroku. Heroku gives a random port number which will be specified as process.env.PORT. how could I get that port in my WebSocket service?
My questions are:
How to deploy two servers in Heroku?
How port number in appserver.js is specified as port number in WebSocket service in Angular?
Is there any use of the .env file and ProcFile to solve my problem?
Is there any use of multi-buildpack which is in Heroku to solve my problem?
You cannot deploy two separate servers when they each require a port. You will have to put them into separate apps. In some cases you can combine web servers. Deploying a server is done as regular.
When deploying a web service on Heroku Heroku provides you a port to which you have to bind to. You can then visit your web service under <appname>.herokuapp.com. (<-- this is why 1.) requires you to put them into separate apps.). Furthermore when you connect to the webservice you merely give the URL. That URL is automatically translated into <ipaddress>:<port>. So in your frontend you are not going to specify a port number. You are specifying the websocket URL in your frontend without any port.
In your web server you bind to process.env.PORT.
.env file shouldn't be versioned/committed. No use. If you require environment variables you can set them through Heroku's dashboard. Procfile is not required since you are using Node.js it will look into your npm start script located in package.json. But it doesn't hurt to have since it gives clarity.
There is no multi-buildpack for this.
If your 2 servers are strictly distinct and use separate protocols. One using http, the other ws you can bundle your two servers into one. Here is an example:
const http = require('http');
const path = require('path');
const express = require('express');
const WSServer = require('ws').Server;
const DateFormat = require('dateformat');
let wss;
let server;
const app = express();
app.use(express.static(path.join(__dirname, './../build')));
server = new http.createServer(app);
wss = new WSServer({ server })
this.wss = wss;
wss.on('connection', function(socket) {
console.log(DateFormat(new Date(), 'm/d h:MM:ss TT'),
`client connected to server (${wss.clients.size} total)`);
socket.on('message', function(data) {
console.log(data)
});
socket.on('close', function(code, desc) {
console.log(DateFormat(new Date(),
"h:MM:ss TT"),'client disconnected, total:', wss.clients.length);
});
});
wss.on('listening', () => console.log('Websocket listening on port', config.get('port')));
wss.on('error', err => console.log('Websocket server error:', err));
server.on('error', err => console.log('Server error:', err));
server.listen(process.env.PORT);
Example in a project:
https://github.com/vegeta897/d-zone/blob/63730fd7f44d2716a31fcae55990d83c84d5ffea/script/websock.js
In the project the backend with the websocket server was extended to include an express server serving the static files. Note that this change only exists in the heroku branch.
You will find all the relevant changes that made that project heroku compatible in this commit:
https://github.com/vegeta897/d-zone/commit/63730fd7f44d2716a31fcae55990d83c84d5ffea
I just made a bot in node.js for the Cisco Webex Teams application. My bot uses "express" and "botkit". "Express" requires listening on the port "3000" and "Botkit" listening on the port "8080".
I tried heroku.com but it does not accept two predefined ports and does not save files dynamically (fs.write)
var PUBLIC_URL = "http://a796e3b7.ngrok.io";
var port ='3000';
var ACCESS_TOKEN ='xxx';
var SECRET = "xxx";
var express = require('express');
var app = express();
var Botkit = require('botkit');
var controller = Botkit.webexbot({
log: true,
public_address: PUBLIC_URL,
access_token: ACCESS_TOKEN,
secret: SECRET,
webhook_name: process.env.WEBHOOK_NAME || 'Email2Webex',
});
controller.setupWebserver(8080, function(err, webserver) {
controller.createWebhookEndpoints(webserver, bot, function() {
console.log("Webhooks set up!");
});
});
app.post('/mailgun', upload.any(),function(req, res, next){
res.end('ok');
});
app.listen(port);
Currently I use ngrok to host the bot locally on my computer and I want to be able to host it on a server so I do not have to worry about it. how can I do ?
You can't set the port on Heroku apps. Heroku sets the port you're supposed to use through the PORT environment variable, and you should use it via process.env.PORT. Generally speaking, deployed applications should not run on development ports like 8080 - if it's an HTTP server, it must listen on port 80, for example.
In order to have two apps listening at the same time, I suggest you refactor your code and include both your bot and your app into a single express server that will listen at the port defined by Heroku's PORT environment variable.
Concerning access to the file system, it is borderline possible to use it, but there are high security restrictions, so a code that might run on your machine is likely to break on the server. Generally speaking it's a bad idea to access the file system directly in Heroku, except for read-only actions on deployed files. That is in part because the file system is ephemeral, so dont assume your written files will always be there. Most issues related to the caveats of using the file system can be resolved by using database or file storage features provided by Heroku, though.
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!
I am working on a multiplayer chess game with NodeJS and socket.IO.
I have problem hosting it on Azure tho.. I tried many different approaches, a few mentioned:
Forcing the application to only use WebSockets by adding the code below:
io.configure(function() {
io.set('transports', ['websocket']);
});
Added <webSocket enabled="false"/> in web.config file..
Note: This disables the IIS WebSockets module, which includes its own implementation of WebSockets and conflicts with Node.js specific WebSocket modules such as Socket.IO. If this line is not present, or is set to true, this may be the reason that the WebSocket transport is not working for your application.
Matching origin protocol to ensure no SSL issues.
io.configure(function() {
io.set('match origin protocol', true);
});
I now started from scratch, since I thought my server-side part was corrupt, and tried Socket.io chat example instead.
I followed the steps.
Created a new web app on Azure.
Published my files through FileZilla FTP.
Enabled Web Sockets on Azure for my app (disabled by default).
STILL THE SAME ERROR! See picture below.
Anyone? I am unsure if it's a client-side or server-side issue. It seems like it's trying to XHR-poll instead of using web sockets..
Thanks in advance.
I got it working, thank you Chris Anderson-MSFT for your help.
The weird thing that occurred for me when deploying with FTP was that my node_modules folder differed with version(s) specified in my package.json.
I solved this by connecting my web app on Azure to a local Git repository and deploying the app through git. This connects my packages recursively and matches correct versions.
I also needed to enforce my client-side socket-io to use web sockets by specifying transport method:
var socket = io({transports:['websocket']});
And this is what my server-side file ended up looking like:
var express = require('express');
var app = express();
var server = require('http').createServer(app);
var io = require('socket.io')(server);
var port = process.env.PORT || 3000;
app.use(express.static('public'));
app.get('/', function(req, res) {
res.sendFile(__dirname + '/public/default.html');
});
io.on('connection', function(socket) {
io.set('transports', ['websocket']);
console.log('new connection on socket.io');
socket.on('move', function(msg) {
socket.broadcast.emit('move', msg);
});
});
server.listen(port, function () {
console.log('Server listening at port %d', port);
});