Microservices for building an IDE
summary
Rider splits IDE features across JVM front-end and .NET back-end and uses an open‑source writer protocol — a Kotlin DSL that generates cross‑language bindings (.NET, Kotlin, JS, C++) and a reactive model with lifetimes. It ships optimistic conflict resolution where the latest edit wins, a signal/list/property primitives set, and socket transport so previews, Roslyn workers, Unity editor hooks and remote/debug containers run as separate processes. Code With Me and remote development already use the same protocol.
AI-written summary · about
chapters (31)
- 0:00Start
- 2:30JetBrains
- 4:43ReSharper IDE
- 5:42Why build a .NET IDE?
- 6:25Cross-platform...
- 8:41So what do you do?
- 10:00Both sides are an IDE...
- 13:54Example: Context actions (Alt+Enter)
- 15:00Example: Inspections
- 15:57Example: Writing code
- 16:45Data types aren't that complex...
- 17:05Which protocol do we use?
- 18:20Request-action-response
- 19:50Conflict resolution...
- 20:46Optimistic conflict resolution
- 21:27Obligatory diagram Rider
- 22:10Rider protocol
- 23:33Primitives
- 24:00Protocol model
- 25:00Hierarchical lifetimes
- 35:59Two processes!
- 37:10Debugging? Four processes. RD
- 37:58Multiple processes.
- 38:58Multiple view models
- 40:13Multiple machines
- 40:43Unity game engine
- 41:58Code With Me
- 42:45Remote Development
- 45:37Every IDE as both a client and server
- 46:27Model the view
- 47:21Summary
related talks
52mMicroservices for building an IDE – The innards of JetBrains Rider
59mMicroservices for building an IDE – The innards of JetBrains Rider
01h 05mIDE wars: us, our friends, our rivals and our...partners
01h 01mWish you were here: stories of building a remote development IDE
01h 01mRider Tips & Tricks
58mWish You Were Here: Stories of Building a Remote Development IDE
40mBecome a Productive .NET Developer with JetBrains Rider
01h 03mMaking a desktop IDE distributed and collaborative