New: Use RxJS

New Pattern Proposal: Use RxJS

We have a lot of different ways to communicate between, among, and within apps.

None of them meet every need nor do they scale to more complex use-cases.

We should implement RxJS as our "data & message communication tool".

Goal / Target

Implementing a tool like RxJS underpins and unlocks asynchronous, non-deterministic, decoupled reactive application architectures.

While those aspects may not be important to all of GitLab, there are certain utilities or new features that absolutely will benefit.
Like the Cold War space race, we may not all need the exact things being researched and implemented, but we all eventually can benefit from them in some way. 😉

A pretty picture

I have summarized some of the features and use-cases that I thought of in this graphic, which contrasts different options.
I think it's pretty fair, but I obviously have an agenda. Please feel free to suggest modifications.
My judgement for whether a tool fits a use-case or has a feature was basically "Is this possible without a bunch of really rough fiddling and custom code?"
Fundamentally, we could probably force any of these tools to do any of these things, but it wouldn't be pretty.

Advantages of new pattern

1. RxJS meets all of our current needs
2. It is not linked to any one technology or workflow
   • It can work in a Vue app with Vuex, or with any other tech
3. Unlike current tools, it can also expand in complexity to stream data (whether over an API or not)
4. It has robust collection-based utilities (e.g. map, filter, debounce, flatMap, etc.), when that feature becomes necessary
5. It has standardized testing utilities
6. It seeks to adhere to proposed language specifications
7. It has very little overhead

Disadvantages of new pattern

1. Some folks find reactive programming to be very confusing
2. It necessarily means abstracting the concept of communication from other concepts (like rendering, componentization, statefulness, etc.)
   • This is a positive - to me - but some folks prefer tools that "do it all"
3. It's more code
   • About 28k for the basic implementation
   • Slightly increases memory usage, but only once, at instantiation. Later usage does not create more memory consumption.
   • Ideally, this would replace other existing implementations and offset it's own weight by subsuming the utility of other libraries

What is the impact on our existing codebase?

As noted above: there's a small memory and code-size impact. It's about 1-1.5% in both cases for "median" / typical apps.

In terms of development workflows, there probably wouldn't need to be much.

At some point:

• We could replace the inner implementation of event_hub_factory.js with an RxJS-based implementation
• We could replace frightful shared Vuex stores (like how Notes and Diffs both require each others stores, because they HAVE to communicate with each other) with a single cross-app messaging implementation based on RxJS

...but none of these are absolutely required.

Reference implementation

Direct to branch

Integration MR: gitlab-org/gitlab!87317 (closed)

Demo of usage: gitlab-org/gitlab!87951 (closed)