Requests accepted by Broker.
Result of running a Request, narrowed by request variant:
Resource existence request.
Resource retrieval request.
Collection retrieval request.
Resource mutation request.
Batch handler for a single request type.
A queued request paired with its promise-resolution hooks.
Request-submission surface over the batching handlers.
Creates a batching store client backed by a set of request handlers.
Batching store client.
Lets a connector serve many concurrent store requests with few backend round-trips. Requests of the same kind are coalesced into a single batch, and the connector supplies one batch Handler per kind. The resulting StoreClient adds conditional CRUD semantics on top, so handlers apply each request unconditionally.
Four request kinds partition the work, each with its own handler:
detect— probes whether each Detect entry exists in the storedetail— materialises each Detail resource against itsmodel; multi-valued members reached by the model may be handed to theselecthandler through Broker.selectselect— materialises each Select collection against itsquery; element resources reached by the query may be handed to thedetailhandler through Broker.detailmodify— creates, updates, or deletes each Modify target, or links it to a collectionRetrieval is driven by the requested
modelandquery, not by the stored graph. Adetailhandler issues aselectfor each multi-valued member its model reaches, and aselecthandler issues adetailfor each element resource its query reaches. Each request thus descends exactly as deep as itsmodelorquerynests, however deep the underlying graph runs.Handlers run concurrently and exchange nested requests through the Broker. A handler must not assume any ordering between handlers, and must await every nested request it issues before settling the request that depends on it.