Define socket structure

[ben-ryder]

How will sockets be setup?

Requirements:

• Users can only listen for and emit their own events.
• Change events - when changes are added.
• Resource Events - when a resource is added, updated or deleted.
• User Events - when a use updates or deleted their account.
• Clients should be able to control what events they want to recieve (for example, only recieving updates to a specfic resource to reduce network load if the user isn't viewing other resources)

Questions

• Each user should get their own namespace?
• Each resource should get its own room?
• Does a client recieve all events even if not listening for them?
• Could I structure sockets in a way that multi-user support would ever be possible in the future?

[ben-ryder]

I'm currently thinking:

• Users Namespace
  • User Rooms - Updates for each user get emitted to a specific user room.
  • User events are emitted by the server following REST API changes like user updates etc.
• Resources Namespace
  • Resource Rooms - Updates for each resource get emitted to a specific resource room
  • User Resource Rooms - Updates for every resource belonging to that user get emitted to these rooms.
  • Resource events are emitted by the server following REST API changes like resource updates etc.
• Changes Namespace
  • Resource Changes Room - Changes events related to a specific resource get emitted to a specific room.
  • User Changes Room - Changes events for any resources owned by a specific user get emitted to these rooms.
  • Changes are emitted by clients and the server relays these events to other clients in the rooms.

Important Notes:

• All connections are authenticated and access controlled via the same service that protects the REST API
• This separation allows clients to decide what they want to connect to, for example clients likely want to always be listening for user events but may only want to get change events when that resource is being used to reduce network load. Having different rooms (resource specific vs all user resources) also lets client decide how best to listen for events based on that application specific use case.
• The REST API is already split up into modules where changes, resources and changes are their own modules. Having a namespace per module will hopefully help maintain that clear separation of concerns.
• I will install the Admin UI to help with local debugging and testing, it may even be useful in production deployments for monitoring and observability.

Remaining Questions:

• Some apps might want to connect to every namespace at the same time. What are the performance implications of that for the client and server? I care more about the client performance and network cost here as server usage is not a problem right now
• How would clients request which rooms they would like to be added to on the server? Likely via some sort of event, but how would those requests work and be authenticated? Likely via the same server auth/access control system and then via a event + ack so the client knows the outcome of their request.
• Changes to users and resources are likely to be less common and real time, although it could be important for clients to learn about resource changes ASAP in case things like encryption keys change. Would a different protocol work better here? Even if theoretically yes, does it really matter yet?