I've been working with Electron for a while, and one thing that keeps bothering me is how IPC is designed. I mean, it's pretty good if you write a simple "Hello, world!" app, but when you write something more complex with hundreds of IPC calls, it becomes... a real pain.
The problems I bumped into:
1. No single source of truth for the API between renderer and main.
2. Channel names are just strings (easy to break, hard to refactor).
3. No real type safety across process boundaries.
4. I have to manually keep main, preload, and renderer in sync.
5. The errors I can see only at runtime.
I tried to think about a better approach. Something on top of a contract-based model with a single source of truth and code generation.
I wrote my thoughts about how the current design can be improved/fixed (with code examples) here:
Ikryanov•1h ago
The problems I bumped into:
1. No single source of truth for the API between renderer and main.
2. Channel names are just strings (easy to break, hard to refactor).
3. No real type safety across process boundaries.
4. I have to manually keep main, preload, and renderer in sync.
5. The errors I can see only at runtime.
I tried to think about a better approach. Something on top of a contract-based model with a single source of truth and code generation.
I wrote my thoughts about how the current design can be improved/fixed (with code examples) here:
https://teamdev.com/mobrowser/blog/what-is-wrong-with-electr...
How do you deal with this in your project?
Do you just live with it or maybe you built something better on top of existing Electron IPC implementation?