Ever wondered how IDE’s are built? In this talk, we’ll skip the marketing bit and dive into the architecture and implementation of JetBrains Rider. We’ll look at how and why we have built (and open sourced) a reactive protocol, and how the IDE uses a “microservices” architecture to communicate with the debugger, Roslyn, a WPF renderer and even other tools like Unity3D. We’ll explore how things are wired together, both in-process and across those microservices.

1. Microservices for building an IDE
The innards of JetBrains Rider
Maarten Balliauw
@maartenballiauw

2. JetBrains Rider
demo

3. Rider
Cross-platform, full-stack .NET IDE
All languages, all frameworks
Even WinForms (on Windows)
Rider C++ in preview
Lightweight, fast & yet a full IDE!
Built on IntelliJ IDEA and ReSharper
Helps you be more productive as a developer
Free trial! https://RiderIDE.net/maarten

4. History

5. JetBrains
Founded 2000 in Prague (Czech Republic)
2000 IntelliJ Renamer
2001 IntelliJ
2004 ReSharper
2020 20+ IDE’s and other developer tools

7. ReSharper IDE
Project was halted (but not gone to waste)
Keep functionality separate from the actual IDE
Same core, IDE interoperability layer on top
Visual Studio 2010, 2013, 2015, 2017 and 2019
ReSharper command line tools (CLI)
Several concepts and architecture remained

8. “When will JetBrains come
with its own .NET IDE?”

9. Why build a .NET IDE?
In 2017…
“When will JetBrains come with its own .NET IDE?”
ReSharper constrained by Visual Studio environment
32-bit process resource constraints
Changes in VS impact ReSharper
.NET Core
No good and consistent cross-platform IDE

10. Cross-platform...
...means a cross-platform UI toolkit is needed!
ReSharper UI built with WinForms and WPF
Existing ReSharper UI would need converting
WinForms? (Mono sort of has it)
GTKSharp?
Qt?

11. IntelliJ Platform
Foundation of all of our IDE’s
Project view, code completion, UI toolkit
+ Platform plugins such as version control, terminal, ...
+ JetBrains <product name> IDE plugins
Open source (build your own IDE – e.g. Android Studio, Comma IDE & others)
https://github.com/JetBrains/intellij-community
Windows, Linux, Mac – already cross-platform thanks to JVM

12. IntelliJ Platform + R# ?
IntelliJ Platform
Great foundation to build on
Windows, Linux, Mac
JVM
ReSharper (R#)
All of those .NET inspections, refactorings, code
generation, project model, ...
.NET

13. Options!
Rewrite R# in Java?
16 years of implementation and knowledge
Would bring 2 R# implementations... Automatic conversion?
Run R# as a command-line process
Already possible (thanks, 2004!)
“Just need our own UI on top”

14. IntelliJ Platform + R# !
Headless R# as a language server
Cross-platform (.NET on Windows, .NET Core on macOS/Linux)
No constraints
It is ReSharper! 2 products, 1 code base
IntelliJ as a thin UI
Control the R# process

15. Both sides are an IDE...
Is IntelliJ IDEA really a thin UI? Three sorts of features...
IJ handles everything
R# handles almost everything
Both IDE’s make a more awesome IDE

16. 1 + 1 = 3
demo

17. How to make them talk?
Inter-process communication

18. Example: Context actions (Alt+Enter)
IntelliJ
Text editor, caret(s)
Alt+Enter key binding
“Language infrastructure” + C# facade
ReSharper
C# language, inspections, actions
IntelliJ
Render actions, may add own entries
Data: a tree of id, name and icon nodes

19. 1. Bi-directional
User can be typing
A refactoring or completion may be injecting code at the same time
2. Can be implemented with delta’s
IntelliJ pushes delta to R#
R# pushes delta to IntelliJ
Can’t really do RPC (user experience would be bad)
How to handle concurrency?
Data: a delta (from line + column, to line + column, text to insert)
Example: Writing code

20. Data types aren’t that complex...
Context actions
A tree of id, name and icon nodes
Inspections
A set of name, icon, severity, tooltip, text range
Writing code
Delta with from line + column, to line + column, text to insert
Fairly simple messages! We can make this generic enough!
e.g. make one inspection work  make them all work

21. Which protocol do we use?
Re-use Language Server Protocol (LSP)?
Great in itself – IDE concepts like window, editor, language, diagnostics, ...
We would need customizations for R# feature set
Or build a custom REST-like protocol?
Experimented with JSON, ProtoBuf, request/response style

22. Request-action-response
LSP and custom protocol are mostly request/response
Every call needs context (which solution, project, file, location in code, ...)
Realization: Why use this “request-action-response” flow? Why RPC?
Both IDE’s share a similar model and architecture
Messages are simple, but for RPC they would need context
(which solution, which file, state info, ...) – overhead!

23. Model-View-ViewModel (MVVM)
IntelliJ is our view, ReSharper provides the model
Protocol is the ViewModel, sharing lightweight data
Project.Files.Add("Foo.cs")
Project.Files["Foo.cs"].Inspections.Add(
"Possible null reference", "Warning", 20, 30, 20, 42);
Both processes can react to such change (observable + observer)

24. Conflict resolution...
Changes to data in shared model can come from IJ and R#
Can still cause conflicts due to features or timing/GC issues
IntelliJ: “I just deleted file foo.cs”
R#: “I just refactored foo.cs”
Solutions!
Locking? (freezes, how to handle deadlocks?)
Conventions!

25. Conflict conventions!
View + Model (or client: IntelliJ + server: ReSharper)
Each value stored in the view model has a version
Updates by the view/client increment the version
Updates by the model/server do not
Only accept changes if version is the same or newer
If not, the change is discarded

26. Rider protocol

27. Obligatory diagram
Ideally, our developers do not have
to know the details of this.
Just create view models.

28. Rider protocol
“Reactive Distributed communication framework for .NET, Kotlin, JS, C++”
Open source - https://github.com/jetbrains/rd
1. Include protocol libraries
and build tools on all sides
2. Write view model in special DSL
3. Generate code
4. Work with generated model
.NET/Kotlin/JS/... code generator
Model definition DSL
Primitives
Conflict resolution, serialization, ...
Sockets, batching, binary wire protocol

29. Rider protocol
Only need to know about a few data types & create model
Conflict resolution, wire protocol, timeouts, ... handled by protocol
Code generated based on the defined view model
Bonus points: no reflection/introspection needed on every run
Hierarchical + lifetimes

30. Primitives
Primitive Description
Signal Event that is fired when something happens
Property Observable value
List/set/map Observable collections
Field Immutable value
Call/callback RPC-style call, needed from time to time
byte, short, int, long, float,
double, char, boolean, string,
securestring, void, enum, ...
Primitives and special types
Aggregatedef/classdef/structdef A node in the viewmodel

31. Signal (event)
Producers/subscribers
Observable/observer
Using lifetime to manage subscription
// Produceevent
interfaceISource<T>{
voidFire(T value);
}
// Subscribetoevent
interfaceISink<T> {
voidAdvise(Lifetimel,Action<T> handler);
}
// Event
interfaceISignal<T>:ISource<T>,ISink<T> { }

32. Property
Signal implementation
Lifetime to manage subscription
// Observableproperty
interfaceIProperty<T>: ISink<T> {
T Value{ get;set;}
voidAdvise(Lifetimel,Action<T> handler);
voidView(Lifetime l,Action<Lifetime,T>handler);
}

33. Hierarchical + lifetimes
Cleanup and resource management
Objects attach to lifetime
Lifetime destroys attached objects
Parent lifetime destroys children
NuGet: JetBrains.Lifetimes
publicclassLifetime: IDisposable{
privateStack<Action> resources
= newStack<Action>();
publicvoidAttach(Actionresource){
resources.Push(resource);
}
publicvoidAttach(IDisposabledisposable){
resources.Push(disposable.Dispose);
}
publicvoidDispose(){
while(resources.Count> 0) {
varresource= resources.Pop();
resource();
}
}
}

34. Hierarchical + lifetimes
Solution
NuGethost
Project
Document
Inspections
PSI (Program StructureInterface)
Class
Field
Method
Document
Inspections
...
Project
Local history
NuGettool window
Project
Editor tab
Inspections
Language
Editor tab
Inspections
Language
viewmodel(Riderprotocol)

35. Rider protocol
demo

36. Rider protocol
Kotlin-based DSL - easy to work with for our developers
Update view model, generate code, work with generated code
Find Usages, Navigation, ... work while crafting model
No need to think about multiple processes, state, conflict resolution, ...
Cross-language, cross-platform
Plugin model for Rider is more complex (IJ and R# parts may be needed)
https://github.com/JetBrains/fsharp-support
https://github.com/JetBrains/resharper-unity
https://github.com/JetBrains/azure-tools-for-intellij

37. Microservices

38. Two processes!
Isolation!
Each has their own 64 bit memory space
Also their own, separate GC
Multi-core machines
Start/stop independently

39. Debugging? Four processes.
Rider (IntelliJ + ReSharper)
Debugger worker process
Your application

40. Multiple processes...
What if certain features were
running in their own process?
No need to run all the time
Own memory constraints
Start/stop/crash independently

41. Shared view model
Pass around a shared view model
to interested parties
Example: Roslyn analyzers/inspections
Pass around “reference” of
[
{ name, icon, severity,
tooltip, text range }
]

42. Shared view model

43. Multiple machines
Socket-based wire protocol
Sockets can be on multiple machines
Example:
Docker debugging
Remote debugging

44. Unity game engine
www.unity3d.com
Extension to view model
Rider plugin
Unity editor plugin
https://github.com/JetBrains/resharper-unity
https://twitter.com/kskrygan/status/1064950644094705664

45. https://twitter.com/kskrygan/status/1064950644094705664

46. Future

47. Model the view as well
public CSharpInteractiveOptionsPage(Lifetime lifetime, ...)
: base(lifetime, ...) {
AddHeader("Tool settings");
AddToolPathFileChooserOption(lifetime, commonFileDialogs);
AddEmptyLine();
AddStringOption((CSIOptions s) => s.ToolArguments,
"Tool arguments:", "Additional tool arguments");
AddHeader("Tool window behavior");
AddBoolOption((CSIOptions s) => s.FocusOnOpenToolWindow,
"Focus tool window on open");
AddBoolOption((CSIOptions s) => s.FocusOnSendLineText,
"Focus tool window on Send Line");
AddBoolOption((CSIOptions s) => s.MoveCaretOnSendLineText,
"Move caret down on Send Line");
// ...
}

48. Multiple machines
WPF on macOS/Linux
Rendering on Windows
Front-end on one machine,
back-end on another
...

49. Every IDE as both a client and server
Front-end and back-end: separate process & memory
Whatever happens in the backend, the frontend can process the user's typing
Bring this technology to other IDE’s?
Reuse WebStorm's HTML/CSS/JS functionality in ReSharper
(e.g. Visual Studio + R# using WebStorm in back-end mode)

50. Summary

51. Conclusion
Rider is an IDE built on
two IDE’s
two technology stacks
Rich and easy programming model was needed to bridge the two
Protocol gave rise to
more than two processes
more than one machine
micro UI
Free trial! www.jetbrains.com/rider

52. Thank you!
https://blog.maartenballiauw.be
@maartenballiauw