Introducing websocket sever to power reactive data on Atlas

[WRadoslaw]

Problem

Currently (on dev) we only refetch specific data when we receive a notification that is strictly pointing at a given object like video or NFT. This causes a problem when a user is not directly considered an active side in a given action (or might not be even logged in) like bidding on NFT or posting a comment/reply. We should still try to keep our UI up to date so that all of the sessions that happen to be on a page where an action took place can see the latest information.

Approach

What we could do is to introduce a server that would be responsible for informing the Atlas about any changes so it can update the UI for everyone involved. (click on the image for better quality)

Abstractions:

• only send events to the users that are in the interest (achieved through rooms)
• only process events from processor (secured by auth token - achieved with namespaces)

Namespaces Docs Rooms Docs

Benefits

• responsive UI for users not directly related to the events
• only users in the interest will receive an events
• no need to refetch data if event was received (only if we decide to go with cache modification approach on Atlas)
• possible removal of notifications polling (less stress on the graphql server)
• easier handling of private notifications if we decide to implement such in the future
• fairly easy implementation into the current codebase

POC

Small POC project can be found in following repo https://github.com/WRadoslaw/atlas-websocket-poc/tree/main

[kdembler]

Could you point out more specific problems we're trying to solve? For stuff like NFT bids you could just quite eagerly refetch specific data you're interested in. From my experience real time updates may be hard to implement. With fairly simple architecture of Orion right now it may not be that problematic but once you need to scale Orion instances horizontally (this will be a must at some point IMO), you need to start introducing message brokers etc to keep them in synch.

[WRadoslaw]

Could you point out more specific problems we're trying to solve? For stuff like NFT bids you could just quite eagerly refetch specific data you're interested in. From my experience real time updates may be hard to implement. With fairly simple architecture of Orion right now it may not be that problematic but once you need to scale Orion instances horizontally (this will be a must at some point IMO), you need to start introducing message brokers etc to keep them in synch.

Well, my main idea was to reduce the number of requests to Orion to keep Atlas in the most recent state, so the user doesn't have to use extra bandwidth, and Orion can focus its resources on more important requests.

About implementing real-time updates, I'm not sure whether you mean Atlas or Orion or both, but when it comes to the Atlas we introduced similar logic to the notifications that allows us to revalidate cache when a notification comes without a need to poll, I assume we could adjust this approach to use cache modification in apollo to update data without new requests.

On the Orion side, I think I get your point, but wouldn't the introduction of such a service allow us to move the necessity of horizontal scaling further in time/growth? Let's say we are some time in the future and a single Orion instance is no longer enough, the second question that comes to my mind is, if we have to scale horizontally, shouldn't we already have proper real-time updates instead of polling? I think it would be nice if we could figure out a solution to support real-time updates now that will not be a pain in the ass when we get to horizontal scaling.