
This post originally began as something quick to help people who were beginning to work with Electorn, but as I kept writing — I kept learning neat histories and tidbits that I also thought were worth sharing. This post is still focused on Electron, but I think it takes some fun twists and turns. Exploring the <a href="#references">references</a> and <a href="#materials">recommended</a> materials is well worth your time, in my opinion.

---

When I began working with Electron, it wasn't clear to me the roles that the renderer or the main process played and how or why I would communicate between them. As it turns out, understanding these two processes are the basis for building any Electron application. This post will look at interprocess communication, models of interprocess communication, and its application in Electron. Finally, we'll end with a basic game of interprocess communication ping pong.

### What is interprocess communication

Interprocess communication (IPC) isn't something specific to Electron but rather a concept that finds its origin in prior to even Unix's birth. It's not clear when the term _Interprocess Communication_ was coined, but the idea of passing data between one program or process dates back to 1964 <sup id="cite_ref-1" class="reference"><a href="#references">[1]</a></sup> on a typewritten piece of paper where [Douglas McIlroy](https://www.cs.dartmouth.edu/~doug/) describes what would become Unix pipes in the third edition of Unix in 1973.<sup id="cite_ref-1" class="reference"><a href="#references">[2]</a></sup>

> We should have some ways of coupling programs like
> garden hose--screw in another segment when it becomes when
> it becomes necessary to massage data in another way.

<div class="byline-italic"><a href="http://doc.cat-v.org/unix/pipes/">The Origin of Unix Pipes</a></div>

He also uses the expression, _"for buggering around with_" which I've never heard but fully appreciate.

We can get a glimpse of McIlroy's vision and IPC using employing [Ken Thompson](http://www.linfo.org/thompson.html) brought together in _"one feverish night"_ <sup id="cite_ref-1" class="reference"><a href="#references">[3]</a></sup> by using the pipeline operator (`|`) to take the output of one program and direct it to another. A command that you're probably familiar with is `ls` which is short for list. We can combine the output of `ls` with another program like `grep`, a search by regex tool, using pipes.

```shell
ls | grep .js
```

<div class="byline-italic">Listing all .js files in the current directory</div>

Pipes are just one form of IPC in unix systems and there are many more such as signals, message queues, semaphores, and shared memory<sup id="cite_ref-1" class="reference"><a href="#references">[4]</a></sup>. Windows also has pipes and many of its own IPC implementations, so it should be no surprise that the browser has its own as well.

If you've used the browser's [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), then you've facilitated communication between different browser windows windows using [Cross-document Messaging](https://html.spec.whatwg.org/multipage/web-messaging.html#web-messaging) which isn't in seperate processes (_as of now_), but does share similar characteristics with IPC.

Communication in Electron follows a different pattern that can be found in both peripheral and software architectures — a bus<sup id="cite_ref-1" class="reference"><a href="#references">[5]</a></sup> and a pipe-like API, the browser's [Channel Messaging API](https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API). The channel messaging API _"...allows two separate scripts running in different browsing contexts attached to the same document ... to communicate directly, passing messages between one another through two-way channels (**or pipes**) with a port at each end._" <sup id="cite_ref-1" class="reference"><a href="#references">[6]</a></sup>

Like most good ideas in Computer Science, the good ones are recycled and pipes are no exception as we see the Channel Messaging API modeling a near 60-year old idea.

### IPC in Electron

In Electron, there are two processes that we are concerned with: **main** and **renderer**. IPC for these processes are facilitated through `ipcMain` (main process) and `ipcRenderer` (renderer process).

You can't go far with Electron's IPC without talking about Node's [EventEmitter class](https://nodejs.org/api/events.html#events_class_eventemitter) and since this has been covered [elsewhere](https://www.freecodecamp.org/news/how-to-code-your-own-event-emitter-in-node-js-a-step-by-step-guide-e13b7e7908e1/), I'm going to continue focusing on the Electron's IPC implementation.

In my opinion, there are two architectures at play:

1. **The event system**: The message-bus/pub-sub like nature of Electron's ipcMain and ipcRenderer inherit from Node's EventEmitter class.
2. **The mechanism for sending data**: A unix-like message passing system managed by the Channel API's [MessageChannel](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel) that facilitates sending

The event system allows us to publish messages to a channel by listening for data emitted to a channel. A channel is a string that ipcMain and ipcRenderer use to emit and receive events/data on.

This, generally, follows this form:

```javascript
// Receiving a message
//
// EventEmitter: ipcMain / ipcRenderer
EventEmitter.on("string", function callback(event, messsage) {});

// Sending a message
//
// EventEmitter: win.webContents / ipcRenderer
EventEmitter.send("string", "mydata");
```

Pay careful attention that `send` is not bound on `ipcMain` and instead is bound to `win.webContents`. See [the docs](https://www.electronjs.org/docs/api/ipc-renderer#ipcrenderersendchannel-args) for more info.

Also, it goes without saying that you can only send a message from a process's respective handler. So, if you're in the renderer process, you should be using `ipcRenderer.send` to send messages to the main process and using `win.webContents.send` to send messages from the main process to renderer process(es).

### Basics of an electron program

In an Electron project, the `package.json` specifies a JavaScript file that Electron treats as your **main process**. The below `package.json` will expect an `index.js` file to exist in the current directory since the `start` script's context is the current directory.

```javascript
{
  "name": "basic",
  "version": "0.0.0",
  "main": "index.js",
  "scripts": {
    "start": "electron ."
  },
  "dependencies": {
    "electron": "^8.2.5"
  }
}
```

<div class="byline-italic">A basic Electron package.json</div>

### Creating the renderer process

Inside of the main process, you can create an instance of `BrowserWindow` which will run its own render process. Creating a basic render process follows these steps:

- Create a hidden browser window
- Load an HTML file
- Show the window once `ready-to-show` is emitted from the `BrowserWindow` instance.

Here is a minimal **main process** that creates a browser window

```javascript
const { app, BrowserWindow, ipcMain } = require("electron");
const path = require("path");
const url = require("url");

function onAppReady() {
  // Create the window
  const mainWindow = new BrowserWindow({
    height: 800,
    width: 800,
    show: false,
  });

  // Load main.html in current directory
  mainWindow.loadURL(
    url.format({
      pathname: path.join(__dirname, "main.html"),
      protocol: "file",
      slashes: true,
    })
  );

  // Once electron 'ready-to-show' is emitted, show mainWindow
  mainWindow.once("ready-to-show", function showMainWindow() {
    mainWindow.show();
  });
}

app.on("ready", onAppReady);
```

<div class="byline-italic">Minimal electron main process</div>

### Communicating between the main process and renderer process

Communication between the main and renderer process is surprisingly easy. I think most use-cases will be from renderer to the main process, so I'll be focusing on that.

To send from the renderer to the main process you can use the `send` method from the `ipcRenderer` module. It takes two arguments a channel as a `string` and an array of arguments as the second parameter.

Though it should be noted that the docs indicate an array, I've found this to also work with just strings or integers.

> ###### ipcRenderer.send(channel, ...args)
>
> - channel: String
> - ...args: any[]
>
> Send an asynchronous message to the main process via `channel`, along with arguments. Arguments will be serialized with the [structured clone algorithm](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm), just like [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), so prototype chains will not be included. Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will throw an exception.

<div class="byline-italic"><a href="">IPC Renderer API docs</a></div>

Inside the renderer process:

```javascript
const { ipcRenderer } = require("electron");
document.addEventListener("DOMContentLoaded", function () {
  ipcRenderer.send("my_channel", "my data");
});
```

And, in your main process you can receive this:

```javascript
app.on("ready", function onReady() {
  // Code to load renderer process omitted here. Refer to above

  // Receive message
  ipcMain.on("my_channel", function (event, arg) {
    // prints "my data"
    console.log(arg);
  });
});
```

**Some notes:**

- I like to use enums or objects that are shared across the renderer and the main process to prevent any errors.

```javascript
const IPC_EVENTS = {
  READY: "ready",
  READY_TO_SHOW: "ready-to-show",
};
```

- The `"my data"` string could be an object, array, or integer, but there are limitations. Do take heed to the documentation excerpt from above for `send`:
  - _Sending Functions, Promises, Symbols, WeakMaps, or WeakSets will throw an exception._

### IPC ping pong

Taking everything we've learned here, we can build a basic game of ping/pong message passing. You can find the code for this demo [here](https://github.com/olingern/electron-ipc-ping-pong)

![output3](https://user-images.githubusercontent.com/1470297/81518491-3bc6db00-930c-11ea-9e63-e634ddc28fdd.gif)

### Addendum

I'd like to thank all of the Electron contributors for all of their work over the years. [Visual Studio Code](https://code.visualstudio.com/) has been one of my favorite developments over the past five years and it's only possible with Electron. As a result of Electron, using Linux as a daily driver is now effortless.

I'd especially like to thank [Cheng Zhao](https://github.com/zcbenz) for his work on Electron and for also taking time to look over this. One thing he did note was the addition of the MessagePort API's coming in Electron v10. For a description of the upcoming additions, take a look at [Jeremy Apthorp's](https://github.com/nornagon) pull request ([#22404](https://github.com/electron/electron/pull/22404)) where he goes over the changes. You can also view the proposal [here](https://hackmd.io/bwzFRWZzRIyewIBc1Vf7DQ?both).

<h2 id="materials">Recommended Materials</h2>

- [Unix Pipeline (Brian Kernighan) - Computerphile](https://www.youtube.com/watch?v=bKzonnwoR2I)
- [How to code your own event emitter in node js](https://www.freecodecamp.org/news/how-to-code-your-own-event-emitter-in-node-js-a-step-by-step-guide-e13b7e7908e1/)

- [Electron Process Architecture](https://www.electronjs.org/docs/tutorial/application-architecture#main-and-renderer-processes)

---

<h2 id="references">References</h2>

1 - McIlroy, Douglas (October 11, 1964). [The Origin of Unix Pipes](http://doc.cat-v.org/unix/pipes/)

2 - [Research Unix](https://en.wikipedia.org/wiki/Research_Unix). (n.d.).

3 - McIlroy, Douglas (n.d.). [A Research UNIX Reader:
Annotated Excerpts from the Programmer’s Manual, 1971-1986](https://www.cs.dartmouth.edu/~doug/reader.pdf), pg. 9

4 - Rusling, David (1996). [Interprocess Communication Mechanisms](https://www.tldp.org/LDP/tlk/ipc/ipc.html)

5 - [PCMag Encyclopedia: Bus](https://www.pcmag.com/encyclopedia/term/bus)

6 - `message-channel-main.md` contributors as of commit [1d15839](https://github.com/electron/electron/commit/1d158399a6bb7fc45d42983f499915b59c9035f8) (April 2, 2020) - [Message Channel Main](https://github.com/electron/electron/blob/master/docs/api/message-channel-main.md#messagechannelmain)


Exploring what interprocess communication is and how Electron facilitates communication between processes.

Blog posts tagged withelectron

Blog posts tagged with
electron