Tracking: Pool API

[jazeved0]

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).