According to Uber it's possible to deploy code to node without restart. Where can I read more about this? I expecting it's not forever or pm2.
That’s where the second strength Uber found in Node.js (quick iteration) comes into play:
through an interactive testing environment called REPL - Read Eval Print Loop - JavaScript allows
developers to deploy new code - and fix the errors that new code may create - without having to
stop any processes.
“One of the things that makes Node.js uniquely suited to running in production is that you can
inspect and change a program without restarting it,” said Ranney. “So very few other languages
offer that capability. Not a lot of people seem to know that ability exists, but indeed you can
inspect and even change your program while it’s running without restarting it.”
Source: https://nodejs.org/static/documents/casestudies/Nodejs-at-Uber.pdf
Related
I have a server application using Node, and sometimes I need to run some script in it. Some examples of scenarios when this would be necessary:
During development, I need to create many entries in the database to simulate an use case.
In production, some bug happened and some information was not correctly stored in the DB, I may need to backfill it.
The way I know how do it in node is to deploy some instance of the server with an endpoint that contains the code to be run.
It is interesting to use the node server because it already has a lot of code that I can reused, for example DAO and safe create/delete funcitons.
Django has a interactive Python interpreter that does this job, but I do not know any similar way to it in Node.
Other strategies of doing this use cases are very welcome.
During development, you can just go with debugging, although that requires triggering a breakpoint. Alternatively, if it's just about your database, there are better external programs to interact with your database.
To actually answer your question: Node does have a VM module to run code and even a REPL module to help writing custom REPLs. This does require some work to link up your APIs though, but doable.
As for how you actually interact with that REPL, there are several options. Using a raw socket (and Telnet), a terminal on your site communicating over a WebSocket, a simple HTTP endpoint, ...
You can add scripts in your package.json to handle this with a path to the script. For example "seed:db": "node ./src/seeder.js -i", "drop:db": "node ./src/seeder.js -d" where the i an d flags will be used to determine if i am inserting or deleting, and can be gotten with process.argv[2]
In what environment should I write the code for the telegram bot so that it works even when the console is not running?
I tried to write code in an online environment, but when I turn it off, the bot does not work.
This depend from the OS you are using (es. Windows, Ubuntu 18.04 etc.), and also from which programming language and which version of it you are using (es. "python 3.6").
If you want to have the code always available to be executed, you need to put the script or the scripts in a server (a dedicated computer) always turned on,you can rent one online or you can do it and set up one by yourself , but this need some knowledge before, and depends on which kind of things you want from your server.
If you're still in the early stage of the bot-development i suggest you to use your localhost or local environment in general to test your work, in this way you can focus to one thing at time , useful especially in your first experiences in developing and coding. If it's not strictly necessary i would focus at one thing at time to learn better step by step.
I'm using node v6.10.0 and trying to figure out why my --debug-brk is so incredibly slow. Without this flag (with just --inspect or --debug), it's almost instantaneous, though the debugger still takes forever to attach.
This one flag dramatically increases the load time. My project is taking 50s+ to start up when debugging is enabled.
Any ideas on how to start debugging this issue?
Edit: To be clear, it's happening across two computers and does NOT happen with Hello World.
Edit 2: More detail. I'm using es6. I used webstorm to log out what was going on and found that it was just taking forever to read all my modules? Perhaps that's what's going on?
Is there a way to speed this up? It's taking 34 seconds just to load all the require statements.
Edit 3: It's absolutely the files and require statements. I moved some of the require statements to only load after the database connection is established. The connection is established instantly, but the process hangs on moving forward after that (again for several, several seconds).
Is there any way to speed this up?
What do you mean by "load time"? Are you talking about time between opening the frontend (e.g. Chrome DevTools) and hitting the breakpoint on the first line of your script?
From your description it sounds like there's an issue with the socket connection being slow. Some things to check:
If the URL your Node.js version outputs has localhost - replace it with 127.0.0.1. Some OSes use DNS to resolve this name and might fail to resolve it or to be slow.
Do you have any issues with the network access? Particular Chrome DevTools version has to be downloaded for your node version, this might be slow.
This might be a bug in particular Node.js version (I cannot recall anything specific that might've caused this). What is puzzling is that it is app specific - when you run with --debug-brk or --inspect-brk no JS is executed until after the debug frontend is connected.
Please consider reporting this issue on Node.js bugtracker - feel free to CC me directly (add #eugeneo anywhere in the bug description)... Is there any chance I could see your code - e.g. is it on GitHub? Also - can you please try a newer Node version?
In the past couple of years NodeJS became a major player in the server landscape - and I really find it hard to believe that there is no decent way to have nodejs run as a service on a linux box. On Windows we have iisnode - but for non Windows environments the forever package is suggested as the way to go - instead of a real solution.
Is there maybe a servicized version of nodejs out there that I could not locate?
There isn't a "servicized" version of Node.js available in the sense you are thinking. Keeping your Node application running (for example in the event of a fatal error) is up to you entirely.
As suggested in the first comment, this is fairly subjective, but really there are two big packages (and one or two alternative methods) for making a service out of your Node application. As you've mentioned, forever is a popular choice. If you've never taken a look at pm2, I suggest doing so, as it offers some services that forever does not. Alternatively, you could search for information on supervisord, which I've had success with in the past. Finally, daemonizing Node with upstart is something to look at if the others don't fit well for you.
I am trying to set up a development environment for node.js. I assumed at first that it requires something similar to the traditional, "localhost" server approach. But I found myself at a loss. I managed to start a node.js hello world app from the terminal. Which doesn't looked like a big deal - having to start an app from the console isn't that hard. But, after some tweaking, I found out that the changes aren't shown in the browser immediately - you need to "node [appName here]" it again to run.
So, my question is:
Is there a software or a tutorial on how to create a more "traditional" development server on your local machine? Along with port listening setup, various configurations, root directories etc (things that are regular in stacks like XAMMP, BitNami or even the prepackaged Ubuntu LAMP). Since I'm new at node.js, I can't really be sure I'm even searching for the right things on google.
Thanks.
Take a look at :
https://github.com/remy/nodemon
it'll allow you to do - nodemon app.js
and the server will restart automatically in case of failure.
To do this I built a relatively small tool in NodeJS that allows me to start/stop/restart a NodeJS child process (which contains the actual server) and see/change configuration option and builds/versions of the application, with admin options available on a different tcp port. It also monitors said child process to automatically respawn it if there was a error (and after x failed attempts stops trying and contacts me).
While I'm prohibited from sharing source code, this requires the (built-in) child_process module, which has a spawn method that returns a child process I guess, which contains a pid (process id) which you can use with the kill method to kill said child process. Instead of killing it you could also work with SIGINT an catch it within your child application to first clean up some stuff and then exit. It's relatively easy to do.
Some nice reading material regarding this.
http://nodejs.org/docs/v0.5.5/api/child_processes.html