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.
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.
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)
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.
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?”