Designing a Pure Python Web Framework | Hacker News Reader

Designing a Pure Python Web Framework

reflex.dev

117 pointspicklelo53 comments

I really like this idea of using Python to create both the frontend and backend. Another lib doing this is https://solara.dev/ . Something I particularly like about Solara is that you can interactively build your app in a Jupyter Notebook, since behind the scenes it's using ipywidgets.

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/ ?

Right now Reflex is meant for full-stack apps, but portability is something people have asked us for.

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.

[1] https://x.com/nikhi1rao/status/1767756284751991035

I have used this to build an internal tool, and that was quite a nice experience.

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.

Thanks for the feedback. I work on Reflex and in a recent release, the team added a template and CLI for creating third-party components and publishing them to PyPI.

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.

Thanks. This helps a lot.

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.

[1] https://github.com/masenf/reflex-local-auth

That's a really good point. Definitely something we need to work out before integrating this into the core framework.

Cofounder @ Dropbase (dropbase.io) here. If you just need to build internal tools with Python or want to build internal tools on top of your existing Python codebase, give us a try. We have granular permission built-in so you can share internal tools with others easily, down to who can use or edit each internal tool you build.

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.

Dropbase looks neat. Couple questions based on my read of the site/github/docs:

- 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?

For those who were familiar with pynecone, this is actually the same framework, just rebranded.

Yes good call out. We started as Pynecone but a company with a similar name forced us to change our name.

Anvil [1] is another "pure Python web framework", where you write both the client and the server code using Python. (The client code gets converted to JavaScript so that it can run in the browser.) Anvil has been around since 2016 [2].

[1] https://anvil.works/docs/app-architecture

[2] https://anvil.works/blog/page/15.html

Doesn't Anvil force you to run stuff on their proprietary service however -- which costs money? (I'm not saying that's not a good option for some people, but it's very different to an open source framework you can run anywhere.)

"The runtime engine that powers Anvil’s app hosting is open source. This means you can host your app anywhere..."

Source: https://anvil.works/open-source

oh wow oh wow!

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

As a general rule, an online server should never be left "open" so that anyone can run arbitrary code there. Such servers quickly get turned into bots for botnets (which do things like denial-of-service attacks for their commanders).

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.

you think botnet operators are going to use anvil? i think you are being tad ridiculous here. this is a bad experience period. ive moved on and sticking to reflex

Google Cloud Functions is another online service where you can run arbitrary Python code "in the cloud" (on Google's servers). They have a free tier. And if you want to use it... you have to give them your credit card information. That's just how services like these work.

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.

I'm so happy that you found out for the rest of us on this one. I agree completely with others on this and I also agree that Anvil isn't what you think it is when it comes to web. I'd rather work with something fresh like Reflex because it's what we've been waiting for in terms of compiling front-end, using modern frontend libs. While I'm sure Anvil can get the job done, I just don't see it handling components like Reflex.

I gave this a go recently, nice work! In a few hours I was able to get a really nice looking UI starting from an example.

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!

Can you call it pure python if it compiles to React? Seems like the abstraction just makes it harder to debug

We need to compile down to React/HTML in the end as it's the only way to render a webpage. By "pure Python" we meant from the developer's perspective they won't have to touch React or Javascript.

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.

Wow, you literally got everything wrong in this comment.

- 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.

I think they meant that rendering can only be done with JS/HTML, and if you want to use React stuff, React also has to be involved. No need to be rude and assume the worst.

Third point seems true though, I would definitely expect to see JS errors should any React libs have issues on their own.

Would you consider it “pure Python” if it targeted a WASM runtime for the browser side component?

Sounds RIGHT to me. You need a modern front-end framework like React.js if you want to avoid state / component hierarchy nightmares that you find by doing the same with vanilla JS. Also, the statement of working with pure Python resonates well from the dev perspective. Makes sense to me!

All programming is abstractions, unless you're using machine code. Abstractions don't necessarily make debugging harder -- done the right way, they can make it easier.

(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 00000000

“ ��,��`Real programmers code it in binary”

machine code is very much still an abstraction

> Yes, you can call it "pure python" if it compiles to something else

There 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.

What would make it easier for me to bet on this is if a few pages made with this could be embedded in an existing Django app, in particular using Django auth. I assume many other people are in that position, with existing Django assets.

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?

I was wondering if WebAssembly has been considered as a compilation target instead of React? Are there major down sides to WebAssembly?

At least one of the advantages in targeting React is being able to leverage the vast existing library of React components to quickly expose new and advanced functionality to the Reflex app.

> writing a lot of boilerplate code to connect the frontend and backend.

OpenAPI. django-ninja supports it out of the box.

What do you use for the frontend?

Usually, I go with openapi-generator and pick the typescript-fetch template. You can use that with whatever js-based frontend framework you want.

i love dash, but multipage and auth start to feel like a stretch. keeping an eye on reflex

I've tried it in my company. It's great, but the builds were annoying because of pip failing to solve the dependencies when using Reflex together with other big libraries.

I'll give it another try in the future.

Hey thanks for the feedback. We're working on relaxing our dependencies [1] to make reflex more compatible. Do you remember what libraries you had the conflict with?

[1] https://github.com/reflex-dev/reflex/pull/2796

This PR is super-helpful -- it's nearly impossible for me to work with projects that pin to specific versions, since it leads to so many conflicts. Having minimum versions like in this PR makes life much easier!

Having no logic in the front-end sounds nice, but how well does it deal with an imperfect network connection? If I have 500ms ping, does that mean I have to wait 500ms for each UI interaction?

It has WebSockets so it at least avoids TCP/TLS connection overhead.

But yeah, that's the downside of any thin client.

What do you mean? WebSockets require a TCP+TLS connection in most cases, unless you're using HTTP3

This looks like a really neat project! The examples certainly feel less “script-like” than streamlit.

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.

Yeah - I've said this elsewhere, but I slightly prefer Litestar over FastAPI for this reason.

I was thinking about Litestar as well. Would be a good fit for this project. I hope the maintainers consider it.

Thanks! we found script-like frameworks like Streamlit are nice for small apps, but hard to reason about for larger apps. We went with a declarative approach more similar to React.

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.

Stay with FastAPI at least for now. Devs love it.

I wouldn’t worry about using FastAPI. Not that your point is wrong but the code base isn’t exactly large and it’s entirely open source. If the project goes off road or something you can always continue on your own fork.

I’m not sure why you wouldn’t use FastAPI for this. It’s popular because it’s really good.

im super excited to use this

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)

Another one? How many web frameworks does Python need?

Yes.

Fuck it. Let's code the web in binary.

Reply on news.ycombinator.com