Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
experimental: sse client support (#592)
>⚠️ This is experimental and a work in progress ## Overview tl;dr: This is a very experimental implementation of streaming in Edge: it both listens to the experimental Unleash streaming endpoint and pushes updates to any listeners subscribing to Edge (in effect mirroring the Unleash endpoint). All related code is behind the "streaming" feature gate. More detail: I have added an event source client to the `features_refresher` file. If the streaming flag is on, we'll spawn a task that takes care of listening to Unleash for events instead of starting the poll loop for flags. There is a new endpoint at `api/client/streaming` (mirroring the Unleash endpoint) that you can hit to start listening for updates. The updates are handled by a new `broadcaster` module (largely stolen from [this Actix example](https://github.com/actix/examples/blob/master/server-sent-events/src/broadcast.rs)). The broadcaster stores its client in a hash map that uses the flag query as the key and maps it to a vec of clients that use the same query. ## Left to do Regarding the implementation: I'm not very familiar with Actix, and I haven't done a whole lot of async / multithreaded rust before, so there's probably gonna be a whole lot of things that we can improve, from the architecture level to the specific data structures used. ~~Also, due to the very time-limited spike we did, we need to actually do some real error handling. There's a good few places where we either ignore errors or would just panic if we ever encountered them.~~ But aside from that, there's a few other things to do too: - [x] Store the streaming url in the urls struct - [ ] Add fetch mode streaming/polling as a CLI option - [ ] The broadcaster needs to store the token used with each client; not just the query (you can have multiple tokens with the same query and those tokens can be invalidated separately) - [ ] We should probably find a more sensible way to use the query as a key in the hash map: serializing it and hashing the string seems roundabout and wonky.
- Loading branch information