codesections
commented
5 years ago Thanks for the code review and suggestions.
I don't like, that we didn't carry on our discussion about the architecture.
I realize you had a different view on the architecture. But—given that there hadn't been movement on that front since I last explained my reasons for preferring Warp and given that I'm the primary developer working on this project—I made an implementation decision.
I also don't like the use of really old libraries such as futures 1.x.
Also, as I already mentioned in this review, I'm pretty much in favor of using nightly Rust.
These two points are related—moving to futures 0.2.x would require nightly Rust. I am not dogmatically opposed to using nightly Rust in production: I could imagine there being performance/code simplification reasons that would convince me to give up some stability. But, in the absence of specific benefits from particular nightly features, I'm inclined to stick with stable Rust for an app we intend to deploy in production.
If you have any thoughts about specific advantages we could gain by switching to nightly, please feel free to let me know and I'll consider them.
sphinxc0re
This PR rolls up several days of work that took place in a side repo which I originally intended to be a test/proof-of-concept repo but that grew into a full implementation.
This implementation switches to Warp as the framework for the primary web server (in large part because Warp offers built-in support for SSE and several other advantages as discussed in #2).
As discussed in #3, part of the difficulty with implementing the streaming server (in either Warp or Actix) was the lack of support for async Pub/Sub connections to Redis. I initially looked in to adding that async support to the Redis crate but eventually decided that the better route would be to implement a low-level connection to Redis that is customized to just the PubSub functionality we need. Accordingly, this PR also contains a custom interface built on Tokio. Using a custom interface should be both faster and simpler, since it does not contain logic for anything other than pubsub—which is all we need.
Finally, I note that the SSE support is currently as feature-complete as it is possible to be without having yet added the Postgress interface this means that all of the endpoints are present and are accessible on localhost. However, none of the endpoints have authentication yet, and the endpoints that should provide user-specific data (e.g.,
/api/v1/streaming/user) are currently hard-coded to provide data for user 1 (the admin). Other than those limitations, however, the SSE implementation is feature complete.