Discussion: Should we have a front-end/back-end split?

[mansellan]

Justification
Rubberduck is currently monolithic - everything runs in-process in the host. This raises performance, stability and testability concerns.

Details
Currently, like every other VBE add-in, Rubberduck runs entirely within the process space of the host VBE. Whilst this is convenient for accessing host resources through the VBIDE interface, it does have several drawbacks:

1. We are constrained by the resources available to the host process, primarily RAM. Large projects necessarily mean large parse trees to be held in memory, which can lead to OOM exceptions even on 64-bit systems with plenty of physical memory available. See Holy RAM, batman! (Out of memory errors and excessively high memory usage) #3347.

2. If we crash, we can take down the host or other add-ins. Even if we avoid this, the host can mark us as unreliable and disable us from loading without explicit user intervention at restart. This is not a good look.

3. There is no natural 'seam' between the COM-focused aspects of host interaction at the front-end and the language-focused aspects of lexing, parsing, resolving and anaylsing at the back-end. Facilitating testing of these concerns relies on careful design of abstractions to ensure proper decoupling.

Proposal
The front-end aspects of Rubberduck (interacting with the host through COM interop) should be strictly isolated from the back-end workloads. This is best acheived by running the front-end as a COM add-in (as currently), but commicating with a back-end running in a separate process on the same machine.

This requires inter process communication over a high-performance, low latency mechanism.

Background
Microsoft, during the design of VSCode recognised the need to separate front-end editors from back-end language analysis. Their driver was primarily to avoid the n:n relationship between editors and supported languages, however the solution they devised can be leveraged for our purposes too.

Language Server Protocol (CCA 3.0) is an open standard which describes an astraction between IDEs ("Tools" in their documentation) and language servers. It allows IDEs to support multiple languages without having to include support directly in their native codebase. Instead, a JSON-RPC request is made to an external process requesting information for source code at a given location.

For example, if a user wishes to find implementations of a virtual function:

1. The (LSP-aware) IDE makes a request to the language server stating "Give me implementations for source file Class1.cls at line 20 character 36.
2. The language server uses its knowledge of the source file, coupled with its analysis, to deduce the correct answer and reply to the IDE
3. The IDE displays the result to the user in an approriate manner

Typically this occurs over stdio, but the protocol itself is transport-agnostic.

Language servers can be authored in any language, regardless of the client architecture. Many IDEs and editors, including Visual Studio, VSCode, Eclipse, Sublime, Atom and even emacs now offer LSP clients either by default or as options or extensions.

Implementation
Rubberduck could split itself into a client/server system, with both running on the user's machine. The front-end would remain as a VBE COM Add-in, but would limit itself to collecting user events and displaying a UI. The back-end would be a separate process, launched by the add-in on demand, which would load source files (either transmitted from the front-end or exported by it), parse, resolve and anylase them, then cache them to respond to front-end requests.

Fortunately, we would not need to implement the LSP protocol from spec. Middleware packages exist for many languages, including a highly active project for C#: OmniSharp (MIT), which is the mainline C# provider for VSCode and part of the .Net foundation. This is made available as a Nuget package for construction of C# LSP clients and servers.

[rubberduck203]

On the surface, this sounds like a great idea. Using half a gig of memory isn’t necessarily a problem, if we’re not using the host application’s allocation to do it. I also very much like the idea of isolating (at least some) of the crashes in the LS process, where it wouldn’t drag down the host app with it. Although, from what I see through issues (and someone please correct me if I’m wrong), it seems most crashes are happening around COM interop. So, I don’t actually know if we get a ton of benefit on crash protection. I’m hoping someone who’s actually committed in the last few years can shed some light on that.

Personally, I’d love to see a proof of concept and would be even more excited if the language server could run Core, because then I would actually be able to contribute code again.

If a PoC proves feasible, we would need to determine if/how things might be moved incrementally or if it’s an all or nothing endeavor.

[mansellan]

Yes, that's fair - most of the hard crashes are from AVs from COM. I just listed it because it is a potential benefit, and the smaller our in-process footprint, the less opportunity for problems.

The server can be any language we want. I vote Core :-)

[retailcoder]

I agree on the principle, but I'm worried implementing the current-tech stuff could turn into a can of worms, given there's obviously zero existing support for VB6/VBA - but definitely worth looking into whether & how it could be done.
What are the advantages of implementing Microsoft's protocol (through a middleware package that handles VB6 code), over making our own server process?

(and yes, I vote Core as well!)

[rubberduck203]

What operating systems do we support these days? Still supporting 7? Does Core run on 7?

[mansellan]

Core 3 will run on 7. 3.1 (LTS), probably will too. Beyond that probably not.

[rubberduck203]

One advantage would be folks who like to use other editors being able to write their own front ends. I recall a few people writing their VBA in VSCode and copy/pasting it back to the VBE.

[mansellan]

Benefits of running LSP: it's an existing, open protocol in this problem space. We don't have to write it from scratch. Side benefits: syntax highligting for VBA/VB6 in Visual Studio, VSCode, Eclipse... NOT suggesting we officially support those...

[mansellan]

Actually, not just syntax highlighting... Any capabilities which are supported by our LS and client X - navigation, diagnostics, code-completion...

[bclothier]

Right now we support Vista at minimum but with mocking PR, that will be dropped because of bump to .NET FX 4.6.1.

I can confirm that the large majority of the crashes are due to COM interactions because those are where we play with unmanaged memory and pointers.

That said, I do see 2 issues:

1. VBIDE itself is single-threaded, so the COM add-in (rather, its UI thread) should be single-threaded. However, I really don't want to dispatch events from LSP to the UI thread. Can we dispatch to the threads behind the WPF controls independently? That would be a big gain, I think.

2. Is the transport protocol going to be fast? I keep hearing about how massively slow ICP is compared to in-proc calls. We must minimize the blocking on the UI thread as much as possible, and if there are too much dispatches that must be made to the UI thread, that might end up being more fragile than keeping it in-process.

[mansellan]

1. Yes, we still own the front end.
2. It runs VSCode, so.... yes?

[bclothier]

I think we need a PoC. Maybe pick up the SlimDucky, set up a toolwindows with a WPF control, then demonstrate that it doesn't crash, etc.

[mansellan]

Agreed, this need proving. Just a proposal at this point, looking for showstoppers...

[retailcoder]

Stupid (?) thought: does enabling VB6/VBA in VSC amount to suiciding Rubberduck as a VBIDE add-in?

[rubberduck203]

Is it possible to new Thread() from within the add-in? It’s a little hairier than more modern async approaches, but I’m willing to bet we could run a message pump that talks to the server if we can.

Will the process be fast? Well, it won’t be as fast as an in process call, because it is a network call and the requests/responses must be serialized/deserialized, but it won’t be as slow as going to an external network.