Tracking: Pool API #57
Description
Rationale
As discussed in https://docs.archit.us/internal/socketio/pools/, the rationale for pools is to provide entity caching on the frontend in a reusable way.
Primary gateway routes
- Single entity request
- Multiple entity request
- Entire pool request
- Fuzzy member search (only for guild members)
Request-Reply implementation details
- Client-originating requests use an odd number (with no serialization guarantees) that are roughly increasing
- Server-originating requests use an even number
Partial replies
For fuzzy member searching (and other pool requests as well), we can perform a partial reply, where two or more response packets are sent in the context of a single request packet (all sharing the same request Id), where partial results can be returned (i.e. returning results from a cache before returning the full results)
Saga-based implementation details
Works based on applying pressure. Pressure can be applied to either an entire pool, a subset of entity Ids, or a fuzzy search query. Pressure applications are designed to group requests when bursts of entities are put pressure on (i.e. user displays in a large table), where pressures are debounced via saga for a configurable interval (though not large, as the socket.io transport model eliminates the need for extensive HTTP/SSL handshakes that would otherwise occur with frequent HTTP requests).
Each pressure application will be a redux action dispatched from the individual containers that consume the entities (if the entire pool is not present).