-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This "Beta" area contains features pending addition to the core specification that are still being tested in the wild. They are fit for initial implementation, and some have been transferred here from the original specification in order to focus the specification on the core feature set.
Please use issues on this repository for discussions and suggestions related to Beta features. Initial suggestions will be considered within issues before a more complete specification is created within Beta.
These transport options cover different levels of complexity and data volume. Note that in all cases polling must be implemented to support a full cache refresh and data download. The real-time transport mechanisms work alongside infrequent polling to keep the data current.
In the case of real time transport failure, a production client implementation can fall back to polling.
Transport Options | Advantages | Disadvantages | Primary Use Case |
---|---|---|---|
Polling (Simple download) | Simple to implement | Does not provide a real-time feed, and heuristic polling will result in patchy sync | Full cache refresh (also can be used in isolation for prototype implementation). |
Webhooks (Real-time) | Less traffic than polling, more server-side control, allows for real-time, uses standard REST interface | Uses many high-latency connections | Basic production implementation |
Server-Sent Events (Real-time) | Optimisation over webhooks as uses one connection, so can handle higher volume | Requires additional libraries | High volume production implementation |
AMQP (Real-time) | Pages can be handed off to the queue to facilitate even higher volume than Server-Sent Events | Requires additional infrastructure | Very high volume production implementation |