Michael Stum Michael Stum - 5 months ago 11
Javascript Question

What is the Client/Server model when using Electron (Atom Shell)?

I'm trying to wrap my head around how Electron (formerly Atom Shell) works.

I'm coming from a traditional, MVC-style web application where a Browser is calling a Controller Action through a Routing System, the Controller then fetches data from a store (File System, Data Base, ...) and renders a View, which is sent back to the Browser. Some Actions may be sending back JSON instead, as they are called through JavaScript/AJAX instead of the Browser actually navigating to them.

I want to create that, but as a Cross-Platform Desktop Application. I know that Atom Shell combines both a Chromium-Browser and a Node.js/v8 runtime, but I'm not sure how they would communicate.

I guess I could run a full on web server (basically, some Node.js HTTP Middleware like Express), but that creates a network-reachable server (which might also trip up firewalls) - one of the reasons I want to make a desktop app is precisely to avoid running a real server. Basically like the MVP/MVVM pattern in a "normal" desktop app.

Can someone give me a few starting points for what I'm trying to do? How would the browser talk to the node runtime (the "Client" as they call it?) to tell it "Hey, fetch my the record with ID 12345" and would the Client return rendered HTML, or would the browser just get a blob of JSON back and render it through a JavaScript templating engine?

Answer

Electron doesn't seem to use Node.js as a web server but merely as an environment to run background JavaScript code, this code can use node modules to access the system. At the same time Chromium provides a user interface for the app, it displays regular web pages that run usual sandboxed JavaScript. Both are being embedded by the Electron executable, the former directly (Node.js can be built as a static library), the latter via libchromiumcontent. In a way, Node.js is the controller part of the application whereas Chromium is the view.

Typically, the concept used for web pages here is that of single-page applications: a web page represents one application window and as such it stays around as long as this window is visible (often for the entire lifetime of the application). Whenever it needs to display something different it requests data from the background code running in Node.js, just like AJAX applications request data from the server. The page itself is not reloaded, usually JavaScript templating will be used to update contents.

There isn't really a server/client relationship here however, the communication can actually go both ways. Both sides can use the ipc module to send messages to each other (main process, renderer). These messages can have any arguments attached to them, these don't need to be encoded explicitly (typically this is implemented by using JSON internally to encode parameters, I didn't verify whether that's the case with Electron). Internally, that message passing is implemented via platform-specific IPC mechanisms, using libuv to be exact.