A big part of the Thali Project is running Node.js directly on “edge devices” like embedded hardware, phones, tablets, laptops, etc. I recently got asked why anyone would want to do this. My short answer is - P2P.
To start with we have to ask, why would anyone want to use Node.js in an app at all? The answer is that Javascript is the most popular programming language around and NPM is the largest package repository around. Put those together and it’s easy to understand why someone would want to write an app using Javascript and NPM modules. But to be fair one can just grab something like Browserify and get both Javascript and NPM in the same app. React Native can do something similar. So why would anyone need to run a node.js server locally on the device?
P2P
One answer is - because you want to support direct peer to peer communication. Typical scenarios include IoT, high speed local data transmission, communication in environments without Internet support, etc.
Let’s imagine you are using Browserify and a WebView and you want to enable p2p communication. There are at least three ways to do this, long polling, Web Sockets or WebRTC. But all three require some central server whose address is known to the peers ahead of time in order to establish a connection. What if you want to support fun things like local discovery and communicate with whatever devices happen to be around if they don’t know each other and even when there is no Internet? Keep in mind, that you might have Wi-Fi but we are talking about the scenario where that Wi-Fi doesn’t currently have a connection to the bigger Internet.
In that case, you need the ability to open network sockets and listen. That isn’t a scenario a WebView can directly support but is literally what Node.js was invented to do.
Thread contention
If you are using something like Browserify then you are running both your UX code as well as your server code on a single thread. It’s Javascript, remember, only one thread? So both types of code have to fight for time.
But if one puts Node.js directly on the device this all changes. The WebView has its own Javascript VM and Node.js has its own Javascript VM. No more contention between UX and server code for the main thread. So if suddenly the server needs to do a bunch of expensive work this won’t change the UX’s responsiveness.
Listening in the background (on Android anyway)
If one uses something like Browserify then the server code will only run when the WebView is running and the WebView is only running when the app is in the foreground. But by putting a node.js server directly on the device we can run it as an Android service which means the server code can be up and listening all the time, even when the App isn’t in the foreground. And yes, Android and Node.js are smart enough that if the server is listening but has no connections then the Node.js code goes to sleep and doesn’t eat battery until a connection occurs.
No WebView (if you don’t want one that is)
If one uses something like Browserify then one really has to use a WebView. But what if you want your server code in Javascript/NPM but want your UX using something else, either native code or something like react native? With Browserify you have to have that WebView. But by running a Node.js server locally you have a separation of concerns. The server can run in Node.js but the UX can be written in anything you want.
Real code re-use
For a long time an argument for using Node.js down on the device is code re-use. Personally I haven’t seen much such re-use since typically the processing model on the client is different than on the server. Modern architectures are hub and spoke and the server, the hub, is doing different things that the spokes. But in a P2P architecture one has a mesh where nodes are peers rather than asymmetric hub and spokes. From my own experience with Thali we really need exactly the same code on embedded devices, on phones, on tablets, on laptops, etc. because they are all doing the same thing such as authentication, authorization, sync, etc. Node gives us a powerful model to do this that is more portable than just about anything but C.
Conclusion
The idea of running the UX and server separately to create an app is nothing new. Electron has been doing this for years on the desktop. Bringing Node.js to the phone just extends the same idea to phones. Phones are the super computers in our pockets. They are insanely powerful devices with far more power than many things we used to call servers. But we seem intent on treating them as little more than dumb terminals. It’s silly and it’s wasteful. By putting a Node.js server directly on the phone we turn them into what they truly are, full fledged devices able to be first class members of on-line communication in all situations without having to depend on anyone else to function correctly. If you want to see what this looks like in the real world check out Rockwell’s Project Stanton.
One thought on “Why would anyone want to write a phone app that embeds Node.js?”