Description
The redis pubsub seems to be just one way of handling the message stream. See WolfgangFahl/pyFlaskBootstrap4#17 for my attempt to use a non redis dependent vresion of flask-sse by mixing with https://maxhalford.github.io/blog/flask-sse-no-deps/
https://github.com/WolfgangFahl/pyFlaskBootstrap4/tree/main/tests has test_sse.py and test_sse_messages.py as a start as well as https://github.com/WolfgangFahl/pyFlaskBootstrap4/blob/main/fb4/sse_bp.py for a start of the blueprint which basically copies code from this repo.
I'd rather get the redis dependency resolved right here by some kind of ducktyping the pubsub part so the implementation can be choosen. To e.g. use a simple solution like https://maxhalford.github.io/blog/flask-sse-no-deps/
https://github.com/MaxHalford/flask-sse-no-deps as replacement
Activity
singingwolfboy commentedon Feb 11, 2021
Hi @WolfgangFahl, duck-typing the pubsub interface is not a bad idea. The problem is that the code in this project is already so short, that I'm not sure what is the real benefit of doing so.
If you wanted to do such a thing, the parts that could be reused with a non-redis interface are: the
Message
class, and thestream()
method on theServerSentEventsBlueprint
class. Thepublish()
andmessages()
methods on theServerSentEventsBlueprint
class are prime candidates for duck typing: you could reimplement them using some other solution that does not require Redis, and everything should just work.However, the main interface for this project is the
sse
object that it exports. I believe that most people just do this:That does not provide any ability to configure the pubsub backend, and trying to change this interface would make it more complex. I would prefer to keep this project as simple as possible, so that others can easily read the code and re-implement it themselves if they want to make major changes.
Does that make sense?
WolfgangFahl commentedon Feb 12, 2021
Hi @singingwolfboy thank you for looking into this.
I have been trying to base my SSE solution on the flask-sse project and found out that the redis needs also motivated the Message class.
At https://github.com/WolfgangFahl/pyFlaskBootstrap4/blob/main/fb4/sse_bp.py there is a different approach now that allows pydispatch to be used as a PubSub or a simple Queue. There is also support for using
as sources for the SSE
In all the design of that approach is much different so that i think duck-typing is not feasible. Migrating from flask-sse will have some effort. The code is in alpha state and not used yet in my projects.
Currently there is only a demo at http://fb4demo.bitplan.com/events
I am hoping that others might love to see a redis-free alternative and I'd appreciate if this alternative could benefit from your experience and the experience of the flask-sse community. Once better tested i intend to add the solution to the relevant stackoverflow answers. For the time being i'd be intested to learn more about usecases in which a redis-less flask sse solution would be useful. The flask-sse with redis has been used in many projects which i find quite impressive. I think this issue can be closed as long as no other party explicitly wants a duck-typed version of flask-sse.