Frontend Strategy for scaling real-time fields

Problem To Solve

• Currently, the logic for subscribing to an a socket connection and issue channel is nested in the real-time assignees component
• In the immediate near term, we want to make all the fields in an issue sidebar update in real time with the same socket connection and channel subscription.
• In the long term, we want to make the entire issue use the socket connection and issue channel to update in real-time so we can deprecate the realtime_changes endpoint.
• This is the first real-time feature in GitLab and there is no existing reference architectures, frontend documentation, or guidance on how to implement real-time subscriptions on the FE in a standardized way.

Proposal

• FE spike to design ideal architecture for handling socket connects and channel subscriptions (i.e. /issue#123, /board123)
• Create implementation plan and roadmap, including tasks for creating reference architecture and good documentation that our product groups can use to hook the frontend into real-time backend subscriptions.

Considerations

• Some fields will be broadcastable while other fields that contain user specific contextual data will be sent to the FE via [triggers]. How should we model the FE GraphQL queries to separate these concerns? If you try to batch a broadcastable and non-broadcastable field together into the same query, it will kick back to only using triggers, which we currently assume will be much less performant.
• Based on comments from @psimyn, it would make sense to work towards having a standalone Vue app for the entire Issue view (this would also make it easy to load/render in Boards and other places).
• In all cases, we will need to support gracefully falling back to non-wss connections for those instances that disable websockets. In a previous life, I implemented this logic during the initialization of the Apollo Client like this example
• Consider trying to keep all conditional logic about data transport as far away from the components as possible -- this way we don't have to create one-off components for real-time and not real time and conditional load them depending on whether wss is enabled or not.