I can't seem to figure out how to get my express server to run a simple function when the server starts up. Where is the appropriate place to call a function to run on server startup, and the proper syntax?
I have the function in my routes file as exports.myFunction = function() { code here};
I've tried sticking it in the app.configure block as routes.myFunction. I've tried changing it in routes to just be myfunction() { code}, then calling it in the configure block as routes.myfunction(), no luck there either. The function needs to stay in the file containing my routes since it alters some global variables there.
I know it's some stupidly simple syntax thing, but I can't seem to find any hints here or on google. Much thanks for any help!
Use this event:
app.on('listening', function () {
// server ready to accept connections here
});
To be honest app returned by express.createServer() is just http.Server, so everything described in nodejs docs related to http.Server make sense for express and railwayjs.
I would keep it simple. In the module where you call app.listen(port), just call your startup function right before (or after) that. If you need that function to reside in a separate module full of other routes, just export it so your main server.js module can invoke it on startup. If you are still not satisfied with that, consider maybe binding an event listener somewhere in express/connect, although I'm not sure an explicit "startup" event is emitted.
In server.js (or whatever module you start your express server), do this:
var myRoutes = require("./myroutes");
var app = express.createServer();
...
app.listen(8080, "127.0.0.1", function() {
myRoutes.myFunction();
});
You can also bind to the "listening" event as #Anatoly says. The docs for the listening event are here.
Related
I created a Node.js API.
When this API gets called I return to the caller fairly quickly. Which is good.
But now I also want API to call or launch an different API or function or something that will go off and run on it's own. Kind of like calling a child process with child.unref(). In fact, I would use child.spawn() but I don't see how to have spawn() call another API. Maybe that alone would be my answer?
Of this other process, I don't care if it crashes or finishes without error.
So it doesn't need to be attached to anything. But if it does remain attached to the Node.js console then icing on the cake.
I'm still thinking about how to identify & what to do if the spawn somehow gets caught up in running a really long time. But ready to cross that part of this yet.
Your thoughts on what I might be able to do?
I guess I could child.spawn('node', [somescript])
What do you think?
I would have to explore if my cloud host will permit this too.
You need to specify exactly what the other spawned thing is supposed to do. If it is calling an HTTP API, with Node.js you should not launch a new process to do that. Node is built to run HTTP requests asynchronously.
The normal pattern, if you really need some stuff to happen in a different process, is to use something like a message queue, the cluster module, or other messaging/queue between processes that the worker will monitor, and the worker is usually set up to handle some particular task or set of tasks this way. It is pretty unusual to be spawning another process after receiving an HTTP request since launching new processes is pretty heavy-weight and can use up all of your server resources if you aren't careful, and due to Node's async capabilities usually isn't necessary especially for things mainly involving IO.
This is from a test API I built some time ago. Note I'm even passing a value into the script as a parameter.
router.put('/test', function (req, res, next) {
var u = req.body.u;
var cp = require('child_process');
var c = cp.spawn('node', ['yourtest.js', '"' + u + '"'], { detach: true });
c.unref();
res.sendStatus(200);
});
The yourtest.js script can be just about anything you want it to be. But I thought I would have enjoy learning more if I thought to first treat the script as a node.js console desktop app. FIRST get your yourtest.js script to run without error by manually running/testing it from your console's command line node yourstest.js yourparamtervalue THEN integrate it in to the child.spawn()
var u = process.argv[2];
console.log('f2u', u);
function f1() {
console.log('f1-hello');
}
function f2() {
console.log('f2-hello');
}
setTimeout(f2, 3000); // wait 3 second before execution f2(). I do this just for troubleshooting. You can watch node.exe open and then close in TaskManager if node.exe is running long enough.
f1();
I'm refactoring my Hapi server to use reusable modules instead of performing logic in my route handlers. I have a plugin registered in my Hapi server for MongoDB connection pooling, which I'd like to be able to access in these modules. Is there a way to export the server object itself, or do I need to rewrite my modules to accept the request object as an argument? I'm using node 0.12.12 and Hapi 8.4.0.
I already tried module.exports = server; in the file where my server is defined, and then requiring the server object from a different file, (both with var server = require('../index.js').server; and var server = require('../index.js')(server);, but I either get an error or undefined.
The closest thing I could find to an answer was this issue from a few years ago, on an older version of Hapi: https://github.com/hapijs/hapi/issues/1260
- but it looks like this was never really resolved.
Well, I'm an idiot, but maybe this will help somebody else out:
It seems module.exports cannot be called within a callback, according to the node documentation. So I moved this statement to the bottom of my index.js:
module.exports.server = server
And then in my other modules, called:
var server = require('../index.js');
And was able to access the plugins contents as server.server.plugins
HTH
I want to design a live updating Node.js Express server, perhaps having a particular route, say /update, which loads a new configuration file. The only concern I have with this right now is that the server could potentially be in any state when the update happens. If I load a new configuration file while there is a JS message being processed for a user request, at the beginning of the user request there could be one configuration and before the request completes there could be a second configuration when the new config file is loaded. The only way I can think of to prevent this is to take down the server for at least one minute (keep the server live, but prevent any incoming requests altogether) and then update the server and put it back online, but then that's not really the best form of hot reloading or live updating is it?
How can I somehow trick the JS event loop so that the config file only gets loaded once all requests have completed and delay any new requests until after the config is loaded?
One algorithm would be:
set a flag "starting re-configuration"
above flag prevents any new requests from being processed (using Express middleware)
check that all current requests are completed (can't think of anything better than a polling loop here)
once above check is done, load new configuration
once configuration is loaded, switch the flag from (1)
Disclaimer: I have not tried this in production. In fact, I have not tried this at all. while I believe the idea is sane, there may be hidden pitfalls along the road which are not currently known to me.
There is one thing that many Node.js developers tend to forget/not fully realise:
There can always be only one JavaScript statement executed at a time.
It does not matter that you can do async I/O or execute a function later in time. No matter how hard you try, all the JS code that you write is executed in a single thread, no parallelism. Only the underlying implementation (which is completely out of our control) can do things in parallel.
This helps us, because as long as our update procedure is synchronous, no other JS code (i.e. client response) can be executed.
Configuration live-patching
The solution to prevent configuration change mid-request is rather simple:
Each request gets its own copy of the application's configuration.
If your application's configuration lives in a JavaScript object, you simply clone that object for each new request. This means that even if you suddenly change the configuration, it will only be applied to new incoming requests.
There are tons of modules for cloning (even deep cloning) objects, but since I believe mine is best I will use this opportunity for some small self-promotion - semantic-merge.
Code live-patching
This is a bit trickier, but should be generally possible with enough effort.
The trick here is to first remove/unregister current Express routes, clear Node's require cache, require the updated files again and re-register route handlers. Now Express will finish all pending requests using the old code (this is because Node cannot remove these old functions from memory as long as the code contains active object references - which it does - req and res) and use the newly required modules/routes for new incoming requests. Old code should get released from memory as soon as there are no more requests that started with the old code.
You must not use require anywhere during request processing, otherwise you risk the same problem as with changing configuration mid-request. You can of course use require in a module-level scope because that will be executed when the module itself is required, thus being synchronous.
Example:
// app/routes/users.js (or something)
// This is okay, because it is executed only once - when users.js
// itself is required
var path = require('path')
// This function is something you would put into app.use()
module.exports = function usersRoute (req, res, next) {
// Do not use require() here! It will be executed per-request!
}
I think that instead of looping a request to the server you can use a Websocket.
That way, when there's a change in the config file that you mentioned, the server can 'emit' a message to the users, so they refresh their data.
If you are using nodeJS and Express, this will help you:
Socket.io with NodeJS
The server will wait for the signal of some user or anybody and emit the signal to all the users, so they get the new data
Node.js:
var express = require('express');
var app = express();
var server = require('http').createServer(app);
var io = require('socket')(server);
var port = process.env.PORT || 3000;
server.listen(port, function () {
console.log('Server listening at port %d', port);
});
app.use(express.static("/PATH_TO_PROJECT"));
io.on('connection', function (socket) {
socket.on('someone update data', function (data) {
socket.to(socket.room).broadcast.emit('data updated', {params:"x"});
}
});
Meanwhile, the client will be listening if there's any change:
View.js:
var socket = io();
socket.on('new message', function (data) {
liveUpdate(data);
});
I hope I understood correctly what you asked
This is a good problem to solve.
A possible solution could be:
That you derive the controllers on each path from a parent controller. The parent controller can flag a property ON (a flag / file) when a request arrives and turn it OFF when the response is sent back.
Now subclass this parent controller for each express end-point facing the front end. If you make a request now to '/update', the update controller would know if the server is busy or not through the FLAG and send back a reply if the update was successful or not.
For update failures the front end could possibly post back to the '/update' end point with some back-off scheme.
This scheme might work for you ...
I've been doing alot of testing with socketIO and have got stuck with handling situations where my node app is simply offline. The documentation provides no real insight into this issue.
So if i run my website and node app is simply not running, console.log gives:
GET http://[url]:[port]/socket.io/socket.io.js
Uncaught ReferenceError: io is not defined
This is hardly surprising, how ever what i don't understand is how to handle these errors and simply have the script try to attempt a reconnect until it finally does reconnect (if ever).
My script looks like this:
<script src="http://[url]:[port]/socket.io/socket.io.js"></script>
<script>
windows.onload = function()
{
socketio = io.connect("http://[url]:[port]");
socketio.on('connecting', function() {
console.log('trying to connect');
});
socketio.on('connect', function() {
console.log('connected');
});
}
</script>
Is there a way to handle this kind of problem ?
When the server is offline, your initial <script> tag to load the Socket.io client library fails, so you never get the io object in the first place.
To retry, you can add a new <script> tag to load the same URL again and see if it succeeds.
Better yet, copy the socket.io client library to the server hosting your HTML, so that the script will always load. You can then simply handle connection errors from io.connect().
There are a few events that you can bind to.
socket.on("connect_failed", function() {
// Do whatever you wanted to do on failure
});
For a full list of exposed events check here: exposed socket.io events
Edit
Ah, I'm sorry. I misunderstood your question. I thought you wanted to handle when the socket server was offline. If you want to handle not being able to get at the socket.io client script, maybe you could check if socket is null or undefined and handle thought that. Then also fire a setTimeout function to try and load the script asynchronously after a wait period and then check if socket is still undefined or null. Or, as the other answer suggests, pack the socket.io client library with the rest of your HTML page.
I have a to access the config variables defined in the file called
test.js which has --
var aws = require('aws-sdk');
exports.connect = function(){
return aws;
}
Now I need to access it when the OnClick event occurs on the browser. I have this script but the require module does not work.
clientScript.js
var aws = require('../scripts/test.js').connect();
function getValue() {
aws.describe({},function(){...})
}
How can I access this aws variable?
Hopefully I'm not too far off the mark with what you're trying to do here. My understanding (cobbled together between this and your previous question is that you would like something in the browser that upon click will retrieve some status information from an external API, which will then be displayed in the client.
What I would recommend doing (based on the above assumption) is defining your desired function as something to be triggered by an HTTP request to the Express server, which can perform your function and send whatever you'd like from its process back to the client.
In your server define (assuming your Express variable is app)
app.get('/request', someFunction);
In someFunction define what it is you'd like to do, how it relates to the request and response, and what to send back to the client. Express will expect the function to take request and response as arguments, but you don't necessarily need to use them:
someFunction(req,res) {
//do whatever I'd like with aws or anything else
res.send(foo); //where foo is whatever JSON or text or anything else I'd like the client to have to manipulate
}
On the client, you would have a function bound to onclick that would make the request to that /request endpoint. This function could use AJAX or simply render another page entirely.
This sort of organization also leaves display and behavior to the client, while the server deals with retrieving and manipulating data. This layout also resolves any concerns about require() statements on the clientside (which, while possible with things like Browserify, are not necessary and may make the code more confusing).
You can't use require() on the client side, that is only a server side function provided by node.js which runs on the server. If you need config options that are shared between server and client, then you will need to make a few changes to your test.js file so it will work in both. I'm sure there are a number of ways to do this, but the way I prefer is:
Put all your configuration variables inside test.js into an object like:
this.ConfigOptions = {option1:value1, option2:value2};
The client would include the file like this:
<script src="test.js" type="text/javascript"></script>
and can access the config options via the ConfigOptions object
while the server would use require() to include the file and access the config options like this:
var ConfigOptions = require('test.js').ConfigOptions;