Process_Architecture

This prototype uses the process architecture that Electron mandates (see http://electron.atom.io/docs/v0.37.2/tutorial/quick-start/). That is a main process with no UI, multiple UI processes for top-level windows and multiple processes for web-content views (tabs most commonly).

It should be possible to switch to other rendering engines and maintain this overall architecture, the Graphene project for example intends to be a drop-in replacement for Electron using Servo as a renderer (https://github.com/servo/servo/issues/7379#issuecomment-189947770). Doing so requires implementing the APIs used to open windows, display web views and communicate with the OS and FS. That means either including Node with V8 and writing modules that match Electron's or using a different JS engine and providing equivalents to the Node built-in modules and a way to compile any binary Node modules that are included in the prototype.

#Main process#

The main process is a singleton and runs for the lifetime of the application and displays no UI. It is up to the main process to open any UI needed for the application and provide any background services that the application requires. When started a JavaScript file is run in the process and is responsible for starting everything necessary. The script has access to all normal Node APIs for accessing things like the filesystem, operating system and opening network connections as well as some electron APIs.

Modules used in the main process must be loaded from the filesystem or Electron's custom ASAR packaging format which means that hot module reloading isn't possible. We still pre-compile the modules used in the main process to allow for more modern ES7 features like module imports and async functions though.

#UI (Renderer) processes#

Each top-level window opened currently runs in a separate process and has full access to Node APIs for accessing the file and operating systems and certain Electron APIs. The prototype will likely not rely on UI processes being in different processes and there may be performance benefits to switching to a single processes for all top-level windows.

We currently use webpack to compile all the modules used in the UI process to a single JS file with hot module reloading support as well as giving access to modern ES7 features.

#Content processes#

Every page displayed in a webview tag is loaded in a separate content process. Webpages run in a sandboxed fashion with no access to the OS and filesystem however it is possible to preload some JavaScript in the content process that has access to the Node APIs and can send and receive messages from the other processes and access the webpages.

##Inter-process communication##

Communicating between the processes happens through IPC. Electron provides APIs for this in the webContent, ipcMain and ipcRenderer modules. We might choose to wrap these to make switching to other IPC methods easier. We may want to do this regardless since the webContents module relies on Electron's remote module which uses a lot of synchronous messaging and may be a performance problem.

##Including web views##

Electron allows us to embed web views in the UI using the <webview> tag. We are almost certainly going to be wrapping this with a tag because of an incompatibility with React. This means that if we were switching to a different platform we might just need to roll in a different tag to create whatever that platform provides.