IPC Grundlagen

Die zwei Prozess-Welten

Eine Electron-App besteht immer aus mindestens zwei Prozessen:

Renderer haben bewusst keinen direkten Zugriff auf Node-APIs — das ist der Sicherheitskern von Electron. Wenn der Renderer etwas im Dateisystem will, muss er den Main fragen. Das passiert via IPC.

Zwei IPC-Patterns

Electron bietet zwei Varianten:

invoke/handle ist der moderne Default — Promise-basiert, eleganter, klare Request-Response-Semantik. send/on ist die ältere Variante, sinnvoll für Push-Nachrichten vom Main an den Renderer (Notifications, Status-Updates).

Das sichere Pattern — contextBridge

Der Renderer darf ipcRenderer nicht direkt benutzen. Dafür gibt es das Preload-Skript: ein privilegiertes Stück Code, das Zugriff auf beide Welten hat und über contextBridge eine kontrollierte API ans window-Objekt hängt.

main.js — Fenster mit Preload starten

import { app, BrowserWindow, ipcMain } from 'electron';
import path from 'node:path';
import { fileURLToPath } from 'node:url';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

function createWindow() {
    const win = new BrowserWindow({
        width: 1200,
        height: 800,
        webPreferences: {
            preload: path.join(__dirname, 'preload.js'),
            contextIsolation: true,
            sandbox: true,
            nodeIntegration: false
        }
    });

    win.loadFile('index.html');
}

// Handler für vom Renderer aufgerufene Methoden
ipcMain.handle('app:get-version', () => app.getVersion());
ipcMain.handle('dialog:greet', (_event, name) => `Hallo, ${name}!`);

app.whenReady().then(createWindow);

app.on('window-all-closed', () => {
    if (process.platform !== 'darwin') app.quit();
});

ipcMain.handle('kanal', handler) registriert einen Promise-fähigen Endpunkt. Der Handler bekommt das Event-Objekt und alle Argumente, die der Renderer mitschickt.

preload.js — die kontrollierte Brücke

import { contextBridge, ipcRenderer } from 'electron';

contextBridge.exposeInMainWorld('api', {
    getVersion: () => ipcRenderer.invoke('app:get-version'),
    greet:      (name) => ipcRenderer.invoke('dialog:greet', name)
});

exposeInMainWorld('api', {...}) legt das Objekt unter window.api im Renderer ab. Wichtig: NUR die Methoden weiterreichen, die der Renderer wirklich braucht — nicht das ganze ipcRenderer-Objekt. Sonst hebelst du die Sandbox aus.

renderer.js — sauberer Aufruf aus dem Renderer

const version = await window.api.getVersion();
console.log('App-Version:', version);

const message = await window.api.greet('Anna');
document.getElementById('greeting').textContent = message;

Im Renderer existiert ipcRenderer nicht — nur die explizit über contextBridge exponierte API.

Main → Renderer — Events vom Main

Für Push-Nachrichten (Status-Updates, Progress, Notifications) geht es andersherum:

// beliebiger Trigger im Main
win.webContents.send('download:progress', { percent: 42 });

contextBridge.exposeInMainWorld('api', {
    onDownloadProgress: (callback) => {
        const listener = (_event, data) => callback(data);
        ipcRenderer.on('download:progress', listener);
        return () => ipcRenderer.removeListener('download:progress', listener);
    }
});

const unsubscribe = window.api.onDownloadProgress(({ percent }) => {
    updateProgressBar(percent);
});

// beim Cleanup
unsubscribe();

Das Cleanup-Pattern (Unsubscribe-Funktion zurückgeben) ist Pflicht — sonst sammelst du Listener bei jedem Re-Mount der UI an.

invoke vs. send im Vergleich

Faustregel: für Renderer fragt Main immer invoke/handle. Für Main pushed an Renderer webContents.send + ipcRenderer.on.

Channel-Naming und API-Design

Channels sind nur Strings — Typen werden nicht erzwungen. Konventionen helfen:

// gut: namespace:action
ipcMain.handle('files:read', ...)
ipcMain.handle('files:write', ...)
ipcMain.handle('window:minimize', ...)

// weniger gut: flach
ipcMain.handle('readFile', ...)
ipcMain.handle('minimize', ...)

In TypeScript-Projekten lohnt sich eine zentrale Channel-Map mit Typen — dann sind Tippfehler beim Channel-Namen Compile-Errors.

Weiterführende Ressourcen

Externe Quellen

• Inter-Process Communication — Offizielles Tutorial mit allen Patterns
• ipcMain — API-Referenz
• ipcRenderer — API-Referenz
• contextBridge — API-Referenz und Best Practices
• Process Sandboxing — Hintergrund zum Sandbox-Modell
• Security Checklist — IPC-relevante Sicherheits-Punkte

Verwandte Artikel

• Was ist Electron?
• Projektstruktur
• Setup und erste Schritte