Designing a Pure Python Web Framework(reflex.dev) |
Designing a Pure Python Web Framework(reflex.dev) |
Has anyone compared Solara and Reflex and can comment on pros/cons? Are there other options in this space? Maybe https://shiny.posit.co/py/ ?
We're working on making Reflex work in different environments like Jupyter notebooks, and we're also exploring using Reflex for widgets [1] that can be embedded in pre-existing apps, so you can add interactive Python elements easily without rewriting your whole app.
My main complaint right now is that it's quite a bit of work to build authentication. I think there are some examples somewhere that show you how to do it. But given, how common it would be for people to use authentication, it should be built in as a first-class object.
Since then, I've built a few authentication libraries that might be of interest:
https://github.com/masenf/reflex-local-auth https://github.com/masenf/reflex-magic-link-auth https://github.com/martinxu9/reflex-google-auth (documentation WiP)
The problem with having auth built in is that it's been hard to find a solution that actually works for a majority of use cases. That said, as these auth libraries get more popular and refined, they might be moved into the reflex-dev organization as officially maintained components, or even integrated with the core framework.
However, I am concerned that the @reflex_local_auth.require_login decorator [1] merely redirects users to the login page.
> Although this seems to protect the content, it is still publicly accessible when viewing the source code for the page! This should be considered a mechanism to redirect users to the login page, NOT a way to protect data.
So, I have to put an if-else condition on the State data associated with each protected page, in addition to this decorator. The reasonable way to do it would be for the decorator to actually prevent any data load at all before redirecting. This will prevent a lot of mistakes, besides removing boiler plate.
For context, we're a more niche cousin to Reflex that's specifically designed to build internal tools. Reflex seems to be a more general framework to build anything you want; quite powerful, and possibly an easier to use Django replacement.
It's awesome to see frameworks like Reflex. I think the Python ecosystem needs this.
- is the architecture exclusively hybrid SaaS? Looks like I host a worker node but a cloud connection is still required.
- how can I monitor the data flow between the local worker and hosted orchestrator? I assume it’s straightforward to turn on verbose logs on the worker’s requests out.
- is the IDE hosted locally or remotely?
- authentication to local services appears to be done primarily through credentials hardcoded in the ENV file. How can I use SSO and pass user authentication to the upstream data sources?
I got a bit frustrated when it came to managing state though. I struggled to mutate and view the same state across all web users, instead of creating state per user that connects. However this is still a great framework I’ll definitely revisit in the future!
We only use React for the UI layer and to send events. Since all the state/logic is kept in Python you won't see Javascript errors during runtime, and debugging can mostly be done in Python land.
- There are a thousand ways to render HTML, you don't need React at all. Even for interactive pages (see recent alternatives like HTMX, or decade old solutions...)
- If it is converted to JS/React it's obviously not "pure" Python. Sorry, but that's just silly to say that.
- You will definitely see JavaScript errors during runtime, it's inevitable. Maybe not with simple toy projects, but with serious projects, it will happen and will make life miserable.
(Yes, you can call it "pure python" if it compiles to something else, because every programming language compiles to something else.)
10100010 00000000
10111101 00010011 00001000
10011101 00000000 00000100
11101000
11100000 00101100
11010000 11110101
01100000
01010010 01100101 01100001 01101100
00100000 01110000 01110010 01101111
01100111 01110010 01100001 01101101
01101101 01100101 01110010 01110011
00100000 01100011 01101111 01100100
01100101 00100000 01101001 01110100
00100000 01101001 01101110 00100000
01100010 01101001 01101110 01100001
01110010 01111001 00000000There is an idea that "pure python" means python + python runtime.
For example, pg8000 is a "pure python PostgreSQL driver", but psycopg is not.
Even though both of them only require Python code from their users.
I get that it's not straightforward because it's based on FastAPI and has its own ORM based on SqlAlchemy, both of which have different async behavior than Django, but is it possible to maybe host a Django app and Reflex app in the same process, routing between the two at the WSGI/ASGI etc. level, and only interact with the Django auth middleware?
OpenAPI. django-ninja supports it out of the box.
I'll give it another try in the future.
But yeah, that's the downside of any thin client.
One thing I find disappointing though, is that this framework is built on top of FastAPI. I feel it’s a bad idea to build on top of what’s basically a one-man project. No matter how popular that project is.
FastAPI has been working well for us, but we're not strongly coupled to it - in the future it would be easy to swap it out if needed.
I’m not sure why you wouldn’t use FastAPI for this. It’s popular because it’s really good.
it has a lot potential
just needs more tutorials and github projects using it
i feel like this scratches a lot of itch and the HN comments here aren't doing it justice.
I am not even an investor in reflex and im using it and i love it
frontend for backend (python)
Source: https://anvil.works/open-source
i didnt know about this, this goes even further with a UI editor (that is a killer app)
I'm going to have to pause reflex (im still loving it so far) and take a look at anvil here because it seems to be more mature and baked product than reflex as it stands
one thing i appreciate about Reflex is it feels programmatic and familiar with background in python backend...so maybe its suitable for more limited scope items? perhaps UI editor like anvil is what reflex needs to implement?
Anvil just takes my breath away, i can't believe i never saw this before
edit: okay so i got excited and to run one of the boilerplate apps I need to enter my credit card for a 7 day trial for my python environment to make the app work properly ?! this is such a bad experience for new developers. now i understand why nobody around me suggested it. sigh....going back to reflex.dev
I suspect Anvil has that credit card requirement to prevent botnet recruiters from abusing Anvil's free trial. (Anvil lets signed-up users run arbitrary Python code on their servers.) By asking for a credit card, Anvil has the information they need to go after anyone who violates their terms of service.
Reflex doesn't have to ask for a credit card because you can try it out locally. With Anvil, there is no local dev, you do all the dev in your web browser, in the Anvil Editor app. It's not just a web framework; it's a Rapid Application Development suite.
Third point seems true though, I would definitely expect to see JS errors should any React libs have issues on their own.
Reflex has nothing like that: you can't run your Python code on their servers, yet --- and once you can, you can be sure they're not going to let you try it for free without asking for your credit card.