Electron pro desktopové aplikace

Proč Electron a co přináší

Electron umožňuje vytvářet multiplatformní desktopové aplikace pomocí webových technologií (HTML, CSS, JavaScript). Kombinuje Chromium pro vykreslování uživatelského rozhraní a Node.js pro přístup k systémovým službám. Výsledkem je jednotný vývojový stack, rychlý prototypovací cyklus a rozsáhlý ekosystém knihoven. Electron však přináší i specifické výzvy – velikost binárních souborů, nároky na paměť a přísná bezpečnostní pravidla.

Architektura: main proces, renderer procesy a IPC

  • Main proces – spouští aplikaci, spravuje okna (BrowserWindow), menu, systémová API, životní cyklus aplikace, automatické aktualizace, notifikace a integraci s operačním systémem.
  • Renderer procesy – jeden nebo více pro každé okno či záložku; běží na jádře Chromium a vykreslují uživatelské rozhraní.
  • IPC komunikace – oddělení oprávnění vyžaduje bezpečný kanál mezi rendererem a main procesem. Používejte ipcMain/ipcRenderer s request–response vzorem, validací zpráv a minimálním počtem povolených kanálů.
  • Preload skripty – běží v rendereru před uživatelským rozhraním; slouží k vytvoření bezpečného rozhraní prostřednictvím contextBridge (tzv. bridging API).

Bezpečnostní model a zásady

  • Sandbox – zapínejte sandbox: true a contextIsolation: true; renderer nepoužívá Node.js API.
  • Zakázání remote – nepoužívejte historické remote API; nahraďte jej vlastním IPC a contextBridge.
  • Content Security Policy – omezte zdroje skriptů, zakazujte unsafe-inline a eval; preferujte bundlery generující hashed nebo nonce skripty.
  • Nahrávání vzdáleného obsahu – upřednostněte lokální soubory (file://) nebo vlastní protocol; pokud je potřeba načítat web, aktivujte webSecurity, allowRunningInsecureContent: false, partition a blokování přesměrování (redirect blocking).
  • Omezená oprávnění – whitelistujte pouze nezbytné metody v contextBridge.exposeInMainWorld. Každé volání validujte (schéma, typy, rozsahy).
  • Bez tajemství v klientovi – API klíče a tokeny nezabudovávejte v aplikaci; používejte backend proxy, systémový keychain a krátce platné tokeny.

Životní cyklus aplikace a správa oken

  • Start: app.whenReady() → vytvoření BrowserWindow a načtení uživatelského rozhraní.
  • Ukončení/zavření: zachytávejte before-quit/window-all-closed; na macOS respektujte vzory reaktivace aplikace.
  • Více oken: pro sdílená data používejte shared workers, vlastní úložiště (store) nebo hlavní proces; nespoléhejte na globální proměnné rendereru.
  • BrowserView vs. WebView: BrowserView je prvotřídní API v main procesu; <webview> je izolovaný tag vyžadující přísnou konfiguraci.

Integrace s OS: nativní menu, tray, protokoly, asociace souborů

  • MenuMenu/MenuItem s rolemi pro standardní chování (kopírovat, vložit, správa oken).
  • Tray – systémová ikona, kontextové menu, indikátory stavu.
  • Protokoly a deep-linky – registrujte app.setAsDefaultProtocolClient('myapp') pro spuštění aplikace z URL.
  • Asociace souborů – otevření souboru v aplikaci (Windows pomocí app.setUserTasks, macOS pomocí open-file eventu).
  • Notifikacenew Notification() s nativní integrací a akcemi.

Přístup k systému: dialogy, schránka, obrazovky, napájení

  • dialog – otevírání/ukládání souborů, varování.
  • clipboard – práce se schránkou (text, HTML, obrázky).
  • screen – informace o monitorech, DPI, dostupném prostoru.
  • powerSaveBlocker – zabránění uspání během dlouhých operací.
  • desktopCapturer – snímání oken a obrazovek (při respektování oprávnění OS).

Výkon a paměť: strategie optimalizace

  • Jednoduché UI – vyhýbejte se nadměrným repaintům, preferujte virtualizované seznamy a memoizaci.
  • Lazy loading – dynamicky importujte těžké moduly; code splitting pro rychlý start aplikace.
  • GPU – ponechte zapnutou hardwarovou akceleraci; vypínejte ji pouze při diagnostice nebo specifických chybách.
  • Procesní model – méně oken znamená méně rendererů; sdílené webContents zvažujte vzhledem k izolaci.
  • Detekce úniků paměti – profilujte heap snapshots, sledujte detached DOM uzly, uvolňujte instance BrowserWindow a rušte IPC posluchače při zničení.

Balíčkování, podepisování a distribuce

  • Bundleryelectron-builder, electron-forge, případně vlastní skripty (CLI + asar archiv).
  • Artefakty – Windows: NSIS/MSIX; macOS: DMG/PKG, notarizace a Gatekeeper; Linux: AppImage/deb/rpm/snap.
  • Podepisování – code signing (certifikát pro Windows, Apple Developer ID), timestamp, správná identita balíčku.
  • Automatické aktualizaceelectron-updater (diferenciální aktualizace), kanály (stable/beta), ověřování podpisů.

Testování: jednotkové, integrační a E2E

  • Jednotkové – čistá logika (store, obchodní logika) pod Jest nebo Mocha.
  • Integrační – testy IPC kontraktů, preload API a chování v sandboxu.
  • E2E – automatizace pomocí Playwrightu nebo náhrad za Spectron (Spectron je již zastaralý); spouštějte electron binárku s testovacím app dir.
  • CI/CD – matrix buildy (Windows/macOS/Linux), cachování node modulů, podepisování v zabezpečeném prostředí (HSM/Apple Notary API).

Bezpečnostní checklist pro produkci

  • contextIsolation: true, nodeIntegration: false, enableRemoteModule: false.
  • Výhradně lokální obsah nebo přísná CSP; blokujte navigaci (will-navigate, new-window události).
  • Preload poskytuje pouze úzké (narrow) API; validace vstupů a serializace zpráv (např. pomocí Zod nebo ajv schémat).
  • Zakázat nevyužitá webová nastavení (např. allowpopups, plugins); povolit safeDialogs.
  • Automatické aktualizace – pouze z podepsaných zdrojů, s kontrolou integrity.

Práce s nativními moduly a systémovými API

  • Node-API (N-API) – stabilní binární rozhraní pro nativní rozšíření; minimalizuje potřebu přestavby při změně verze Node.
  • Prebuilds – distribuujte předkompilované binárky pro hlavní platformy a architektury.
  • Alternativy – preferujte WebHID/WebUSB/WebSerial nebo systémové služby přes main proces, pokud je to možné.

Mezinárodní prostředí, přístupnost a UX

  • I18nmessage catalogs, správa plurálů, dynamické přepínání jazyků.
  • A11y – respektujte standardy Chromium (ARIA, role, kontrast); nativní menu poskytuje klávesovou navigaci.
  • Platformní konvence – klávesové zkratky, role menu a chování oken (macOS vs. Windows) by měly odpovídat očekáváním uživatelů.

Datové úložiště, cache a offline režim

  • Bezpečné ukládání – systémový keychain/Keytar pro tokeny, sqlite/LevelDB/IndexedDB pro data.
  • Perzistentní vrstvy – migrační skripty, šifrování citlivých polí, zálohy a conflict resolution pro synchronizační scénáře.
  • Cache – řízené využití session a partition pro oddělení profilů a tenantů.

Observabilita: logy, telemetry, crash reporty

  • Logy – strukturované logování v main i renderer procesech, rotace souborů a úroveň detailů dle prostředí (env).
  • Crash reporty – integrace crashReporter, mapy zdrojů (sourcemaps) a nahrávání minidump souborů.
  • Telemetry – explicitní souhlas uživatele, možnost odhlášení, agregované metriky (časy spuštění, chybné IPC volání apod.).

Vývojový workflow: bundlery, moduly a ESM

  • Bundling – Vite, ESBuild nebo Webpack pro renderer; samostatné buildy pro main a preload s cílením na Node runtime.
  • ESM – sjednoťte modulární systém; u main procesu zvažte type: module a práci s import mapami.
  • Hot reload – bezpečný pouze pro renderer; restart main procesu může zničit stav – používejte obezřetně.

Alternativy k Electronu: kdy a proč

  • Tauri – WebView + backend v Rustu; menší náročnost na zdroje, velmi přísný bezpečnostní model. Vhodné pro menší UI a nižší požadavky na nativní integraci Chromium.
  • NW.js – podobná filozofie jako Electron, ale s odlišnou integrací Node a webového prostředí.
  • Native cross-platform – Qt, .NET MAUI, Flutter – pokud není prioritou webový ekosystém, mohou nabídnout lepší výkon a nižší nároky na zdroje.

Typické architektonické vzory v Electron aplikacích

  • Command bus přes IPC – centralizace volání do main procesu s autorizací a auditní stopou.
  • Synchronizace store – jednostranný state push z main procesu do rendererů (např. pomocí RxJS kanálů).
  • Modulární preload – několik izolovaných mostů (filesystem, shell, updater), každý s vlastním schématem validace.

Časté chyby a anti-patterny

  • Povolené nodeIntegration v rendereru bez izolace kontextu.
  • Nekontrolovaná navigace a nevalidované zprávy IPC.
  • Obrovské renderer bundles bez code splitting, dlouhá doba do interaktivity (time-to-interactive).
  • Ukládání citlivých dat do localStorage nebo do zdrojů aplikace.
  • Spoléhání na zastaralá API (remote, nekonfigurovaný webview).

Roadmapa implementace: od prototypu k produkci

  1. PoC – skeleton aplikace, bezpečný preload bridge, základní okno, CSP a bundling.
  2. MVP – modulární IPC, logování, základní automatické aktualizace, CI buildy pro tři platformy.
  3. Hardening – sandbox, code signing, audit IPC, profilování paměti a výkonu, crash reporting.
  4. Release – kanály, diferenciální aktualizace, rollback strategie, telemetrické quality gates.

Závěr: kdy je Electron správná volba

Electron exceluje tam, kde chcete rychle doručit plnohodnotnou desktopovou aplikaci s bohatým uživatelským rozhraním, sdílet kód s webovou platformou a využít obrovský ekosystém JavaScript nástrojů. Úspěch závisí na disciplinovaném bezpečnostním nastavení, precizním řízení výkonu a pečlivém balíčkování. Pokud tyto aspekty zvládnete, získáte multiplatformní aplikaci s moderním UX, krátkou dobou uvedení na trh a udržitelnou vývojovou cestou.