I'm using the starter provided by mean.io for a simple MEAN application. Under development I don't have issues with sockjs-node requests:
http://localhost:3000/sockjs-node/info?t=1515290831331
However, once I deploy on Heroku, the application fails to load data using the following requests:
http://sleepy-escarpment-60068.herokuapp.com:8817/sockjs-node/info?t=1515290831331
I decided to test that request using postman, but I had no success as well. However, I noticed a minor issue when trying to request data from that URL. It was that when deployed on Heroku, it adds the port assigned by Heroku which is 8817 in my case. I decided to test a similar URL, but this time without using heroku's port (8817):
http://sleepy-escarpment-60068.herokuapp.com/sockjs-node/info?t=1515290831331
In this scenario, I could receive a response data. Therefore, my idea is to change the path of the URL once the app sends the request from:
http://sleepy-escarpment-60068.herokuapp.com:8817/sockjs-node/info?t=1515290831331
to
http://sleepy-escarpment-60068.herokuapp.com/sockjs-node/info?t=1515290831331
However, I'm not sure neither how to do it, nor where to apply this solution on the application. I've been googling around to find a solution for the /sockjs-node/info?t=1515290831331 issue and people suggest to redirect the request using the webpack.dev.js file:
devServer: {
port: METADATA.port,
host: METADATA.host,
historyApiFallback: true,
watchOptions: {
// if you're using Docker you may need this
// aggregateTimeout: 300,
// poll: 1000,
ignored: /node_modules/
},
disableHostCheck: true,
proxy: {
'**/sockjs-node': {
changeOrigin: true,
pathRewrite: {
'**/sockjs-node': '/test'
}
},
}
I haven't had success trying to implement that solution. Am I doing something wrong on my code? Is that the right solution for the "/sockjs-node/info?t=1515290831331 failed to get response data" issue after deploying my app to Heroku?
Related
I am deploying a web app for the first time, I am following this here - https://learn.microsoft.com/en-us/azure/developer/javascript/tutorial-vscode-azure-app-service-node-03
In the example it uses npm start, but I have been using node app.js to start my application locally. Also my code is using 127.0.0.1, do I change this to the created URL? When I deployed it, I went to the azure URL and got - azurewebsites.net is currently unable to handle this request.
HTTP ERROR 500.
Thank you for any hep!
var config = {
database: {
host: 'db1.mysql.database.azure.com',
user: 'user',
password: 'password',
port: 3306,
db: 'db1'
},
server: {
host: '127.0.0.1',
port: '3000'
}
}
module.exports = config
UPDATE
You can deploy your webapp by git. I have create a new demo for you. You need change mysql info.
PRIVIOUS
I use vscode, follow the official documentation, no need to modify the port, just follow the steps to directly publish it. I suggest you use linux, it will reduce a lot of problems when creating node web app.
You can read the official documentation carefully. The demo I provided can be downloaded and run. The demo supports connection to mysql.
This screenshot indicates successful release.
I am not familiar with express, but it is normal when debugging. This screenshot is consistent with my local operation. Our focus is on publishing and connecting to mysql. Please see the screenshot of local operation below.
I am using Vue.js's API proxying functionality (which internally uses http-proxy-middleware/http-proxy) to forward API requests to my localbackend server. I set it in vue.conf.js like so:
module.exports = {
devServer: {
port: 8081,
proxy: {
'/api': {
target: 'http://localhost:8080',
xfwd: false
}
}
}
}
For some weird reason though, about every other proxied request coming from Chrome is slow:
When a slow request is profiled in Chrome, it looks like below:
Any idea what might be causing this delay between fetchStart and requestStart? When accessing the proxy through 127.0.0.1, the problem goes away for some reason (DNS issues???). Checked the backend, and it responds correctly as well. The problem doesn't exist on Firefox either.
System is latest Win10, checked on stable and canary Chrome.
How can one remove/increase the server side connection timeout from Meteor when using server side routes with Iron Router?
There is a fix when using vanilla Node: https://contourline.wordpress.com/2011/03/30/preventing-server-timeout-in-node-js/
But I cannot figure out where to put the code in the above sample to make it work with Meteor and Iron Router
Here's a sample route:
Router.route('veryslowroute', {
path: '/veryslow',
where: 'server',
action: function () {
// Route never rendered in browser. Reducing value here to 110000 will render just fine
Meteor._sleepForMs(120000);
// These I've tried:
// this.response.setTimeout(0);
// this.response.connection.setTimeout(0);
// this.response.connection.server.setTimeout(0);
this.response.writeHead(200, {'Content-Type':'application/json'});
this.response.end(JSON.stringify({
key: 'Sorry for being so slow'
}));
}
});
So it appears the timeout needs to be set somewhere else. Anybody?
EDIT: It appears that this isn't about NodeJS but Meteor itself, likely the webapp-package. Still couldn't find a workaround. Same thing happens when using webapp directly without Iron Router.
EDIT: Now there is an issue in Meteor: https://github.com/meteor/meteor/issues/3826
I'm trying to connect my reveal.js client and master presentations together using socket.io server.
I did all stuff, that Hakim Se describes on his github page, but socket.io still produces an error, while trying to connect to server.
GET http://0.0.7.156:8080/socket.io/1/?t=1393864538446 net::ERR_ADDRESS_UNREACHABLE
If change 0.0.7.156 to my local machine name, query succeds.
I think I has wrong settings of presentations, but could not understand how to fix them.
Client:
multiplex: {
secret: null,
id: 'a9e10bc1b02efafe',
url: 'localname:1948'
},
Master:
multiplex: {
secret: '13938623264068002486',
id: 'a9e10bc1b02efafe',
url: 'localname:1948'
},
My experience has been that if I use localhost:
url: 'localhost:1948',
Something inside of reveal.js breaks and transforms localhost internally to the "nonsense" address 0.0.7.156 (bonus points to whoever digs into the code and finds the reason for this, I sadly currently do not have the time). If I instead use 127.0.0.1:
url: '127.0.0.1:1948',
Everything works just fine, at least locally for testing.
You will need to change 127.0.0.1 to whatever host name you will use when deploying the slides later on though.
Hope this helps!
I'm trying to hook in socket.io to a Hapi.js server. I've tested the socket.io implementation in vanilla Node.js and everything works great; the server side of the Hapi implementation seems to work fine, but the "/socket.io/socket.io.js" resource is not served to the client.
I've checked the Hapi example, but they only show what to do on the server, and their documentation on the client handshake seems odd: they have a server on port 8000 but say to post for the socket.io handshake to 8080--I've even tried this (which seems wonky and inconsistent with every other socket.io implementation) with no luck.
Thanks!
Hapi 8 has introduced some new intricacies so if anyone if revisiting this issue...
On the client, you don't have to use /socket.io/socket.io.js, instead use
a cdn (https://cdnjs.cloudflare.com/ajax/libs/socket.io/0.9.16/socket.io.min.js)
or serve the file more specifically (http://yoursite.io/js/socket.io/socket.io.js)
Better yet, use something like npm/browserify and (https://www.npmjs.com/package/socket.io-client):
var socket = require('socket.io-client')('http://localhost:8080');
Which ever way you choose to include the client side code above
Hapi 8 will allow you to do something cool on your server with chat like this:
server.js
server.connection({ port: 8000, labels: 'app' });
server.connection({ port: 8080, labels: 'chat' });
server.register({
register: require('./server/plugins/socketIO')
},
function(err) {
if (err) throw err;
});
/plugins/socketIO/index.js
exports.register = function(server, options, next) {
var io = require('socket.io').listen(server.select('chat').listener,{log:false});
io.sockets.on('connection', function (socket) {
socket.on('someAction', function(name, cb) {
...
});
...
});
}
Answer: Load the Client Script from CDN
To answer your specific question: we decided to load the socket.io.js script from the CDN (e.g: http://cdnjs.com/libraries/socket.io ) to make our app load faster. see: index.html#L23
Working Offline ...? (Or Prefer Not to use CDN?)
If loading the client script form CDN is not an option because you are on dial-up or working offline, then use inert and expose the file to your app. e.g:
var Hapi = require('hapi');
var server = new Hapi.Server();
server.connection({
host: '0.0.0.0',
port: Number(process.env.PORT || 3000)
});
// uses https://github.com/hapijs/inert to serve static files
server.register(require('inert'), function () {
server.route([
{ method: 'GET', path: '/', handler: { file: "index.html" } },
{ method: 'GET', path: '/socket.io.js', handler: { file: './node_modules/socket.io-client/socket.io.js' }
]);
server.start(function () {
console.log('Visit: http://127.0.0.1:'+server.info.port);
});
});
module.exports = server;
The client file is located in: your_project/node_modules/socket.io-client/socket.io.js
Up-to-Date Solution/Example with End-to-End Tests
If you are still looking for an example of how to use Socket.io in a Hapi.js app we created a complete one (with documentation/comments & end-to-end tests).
see: https://github.com/dwyl/hapi-socketio-redis-chat-example
Its up-to-date with the latest versions of Hapi & Socket.io and uses Redis Pub-Sub to persist and distribute chat messages.
You can try to copy the socket.io.js file out from the node.js directory to a well-known directory.
I would first confirm that you don't have any firewall issues interfering with the serving of the request.
If a firewall isn't responsible for blocking the request make sure that the src for the javascript file is pointing to the same server and port number, as indicated on the Hapi.createServer line, that you have configured.
If the request reaches the server it will output a debug line in the terminal indicating that it served the file.