How to get rid of redis dependency?

[WolfgangFahl]

The redis pubsub seems to be just one way of handling the message stream. See https://github.com/WolfgangFahl/pyFlaskBootstrap4/issues/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

[singingwolfboy]

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 the stream() method on the ServerSentEventsBlueprint class. The publish() and messages() methods on the ServerSentEventsBlueprint 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:

from flask_sse import sse
app.register_blueprint(sse, url_prefix='/stream')

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]

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

• a function
• a generator

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.