I have a node.js app that is intended to be running all the time. Is a core process that does some specific work for each of our clients.
Today, that app is feed with the clients data by a config (json) file on startup, every time we need to add/remove a client or change a client data, we edit the json and kill/restart the app.
I came with the idea of building another node.js app that should work as a cli to send instructions to the main app, I don't know where to start, is there a solution already for this?
I tought of using sockets to connect the app with the cli, but I feel it overkill.
What's the propper way of controlling a node.js app from another node.js app?
I know this question may be vague and leaves space for discussions and opinions, but I don't know where to start looking for, all my searches give me express.js or forever/pm2 articles.
You could try storing your data in a REDIS DB and subscribing to changes from the node applications. So, you could update the redis and the configuration changes trigger automatically from within node application
See this question
Another method is to emit global events from your CLI and have your apps listen to and update their code as required.
Related
I have a Fastify web server that exposes a bunch of RESTful endpoints. I created my project using fastify-cli and I also use the CLI to run the server locally. I notice that whenever I rapidly call my APIs, I get the following error in my terminal:
You'll notice that I call the same API repeatedly. I don't get any errors in the first two or three calls but, when I call the same API a third or fourth time, the server process crashes and automatically restarts a few seconds later.
Since the logs are sparse, I can't seem to figure out what might cause this issue and I wonder if it is an issue with the CLI itself? Appreciate any help from other Fastify users.
It is a known bug with the watch feature cli issue
not fixed yet.
I'm new to Node JS.
I have a requirement like, I want to create a service in node js (like console app in .net), that service will fetch the data from mongodb and perform some analysis and insert analysis results into that database.
From the web application I want to execute that service and it should be run as independently in behind the screen (should not disturb the web application).
Is this possible in node js ?
I dont know above architecture/flow is make sense or not. Please share your suggestions.
I'm attempting to scale a Node.js application but am a little confused on one piece of it. I moved all my static files to the gateway server running NGINX, and it routes them accordingly. Now looking at the waterfall diagram in Chrome's dev tools, I notice a full second of wait time to access the socket.io javascript file. I'm assuming that is because this is still being accessed from the application server, not the web server. My question is, can I move this file to the web server to have it load faster? It's an npm module so it seems a little fishy to me, like it needs some sort of interaction with the application server to initialize the connection or something. Or am I thinking about this all wrong? Thanks!
What is the recommended workflow to debug Foxx applications?
I am currently working on a pretty big application and it seems to me I am doing something wrong, because the way I am proceeding does not seem to be maintanable at all:
Do your changes in Foxx app (eg new endpoints).
Upload your foxx app to ArangoDB.
Test your changes (eg trigger API calls).
Check the logs to see if something went wrong.
Go to 1.
i experienced great time savings, shifting more of the development workflow to the terminal client 'arangosh'. Especially when debugging more complex endpoints, you can isolate queries and functions and debug each individually in the terminal. When done debugging, you merge your code in Foxx app and mount it. Require modules as you would do in Foxx, just enter variables as arguments for your functions or queries.
You can use arangosh either directly from the terminal or via the embedded terminal in the Arangodb frontend.
You may also save some time switching to dev mode, which allows you to have changes in your code directly reflected in the mounted app without fetching, mounting and unmounting each time.
That additional flexibility costs some performance, so make sure to switch back to production mode once your Foxx app is ready for deployment.
When developing a Foxx App, I would suggest using the development mode. This also helps a lot with debugging, as you have faster feedback. This works as follows:
Start arangod with the dev-app-path option like this: arangod --javascript.dev-app-path /PATH/TO/FOXX_APPS /PATH/TO/DB, where the path to foxx apps is the folder that contains a database folder that contains your foxx apps sorted by database. More information can be found here.
Make your changes, no need to deploy the app or anything. The app now automatically reloads on every request. Change, try out, change try out...
There's currently no debugging capabilities. We are planning to add more support for unit testing of Foxx apps in the near future, so you can have a more TDD-like workflow.
This may be a basic question, but how do I go about effeciently deploying updates to currently running node.js code?
I'm coming from a PHP, JavaScript (client-side) background, where I can just overwrite files when they need updating and the changes are instantly available on the produciton site.
But in node.js I have to overwrite the existing files, then shut-down and the re-launch the application. Should I be worried by potential downtime in this? To me it seems like a more risky approach than the PHP (scripting) way. Unless I have a server cluster, where I can take down one server at a time for updates.
What kind of strategies are available for this?
In my case it's pretty much:
svn up; monit restart node
This Node server is acting as a comet server with long polling clients, so clients just reconnect like they normally would. The first thing the Node server does is grab the current state info from the database, so everything is running smoothly in no time.
I don't think this is really any riskier than doing an svn up to update a bunch of PHP files. If anything it's a little bit safer. When you're updating a big php project, there's a chance (if it's a high traffic site it's basically a 100% chance) that you could be getting requests over the web server while you're still updating. This means that you would be running updated and out-of-date code in the same request. At least with the Node approach, you can update everything and restart the Node server and know that all your code is up to date.
I wouldn't worry too much about downtime, you should be able to keep this so short that chances are no one will notice (kill the process and re-launch it in a bash script or something if you want to keep it to a fraction of a second).
Of more concern however is that many Node applications keep a lot of state information in memory which you're going to lose when you restart it. For example if you were running a chat application it might not remember who users were talking to or what channels/rooms they were in. Dealing with this is more of a design issue though, and very application specific.
If your node.js application 'can't skip a beat' meaning it is under continuous bombardment of incoming requests, you just simply cant afford that downtime of a quick restart (even with nodemon). I think in some cases you simply want a seamless restart of your node.js apps.
To do this I use naught: https://github.com/superjoe30/naught
Zero downtime deployment for your Node.js server using builtin cluster API
Some of the cloud hosting providers Node.js (like NodeJitsu or Windows Azure) keep both versions of your site on disk on separate directories and just redirect the traffic from one version to the new version once the new version has been fully deployed.
This is usually a built-in feature of Platform as a Service (PaaS) providers. However, if you are managing your servers you'll need to build something to allow for traffic to go from one version to the next once the new one has been fully deployed.
An advantage of this approach is that then rollbacks are easy since the previous version remains on the site intact.