Our great sponsors
-
-
flet
Flet enables developers to easily build realtime web, mobile and desktop apps in Python. No frontend experience required.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
hamilton
Hamilton helps data scientists and engineers define testable, modular, self-documenting dataflows, that encode lineage and metadata. Runs and scales everywhere python does.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
fastapi-azure-auth
Easy and secure implementation of Azure Entra ID (previously AD) for your FastAPI APIs 🔒 B2C, single- and multi-tenant support.
Django admin is really extensible. I'm not seeing here how to offer multiple forms against the same model. Eg if a user can edit some of their profile but not the subscription plan field, while a sales team can.
https://github.com/pydantic/FastUI/blob/main/demo/forms.py#L...
> When you run flet build command it ... Packages Python app using package command of serious_python package. -- https://flet.dev/docs/guides/python/packaging-app-for-distri...
It looks like Flet is for client-side code. It lets you write Flutter apps with Python instead of Dart.
> Simple Architecture - No more complex architecture with JavaScript frontend, REST API backend, database, cache, etc. With Flet you just write a monolith stateful app in Python only and get multi-user, realtime Single-Page Application (SPA). -- https://flet.dev
If I'm writing Python that runs on the mobile device, it must talk to a server to read & write data. Doesn't this still require an API backend, database, cache, etc?
We built an app with it -- https://blog.dagworks.io/p/building-a-lightweight-experiment. You can see the code here https://github.com/DAGWorks-Inc/hamilton/blob/main/hamilton/....
Usually we've been prototyping with streamlit, but found that at times to be clunky. FastUI still has rough edges, but we made it work for our lightweight app.
Would you consider giving Shiny (for Python) a try? https://shiny.posit.co/py/ It's (I hope) pretty close to Streamlit in ease of use for getting started, but reactive programming runs all the way through it. The kind of app you're talking about are extremely natural to write in Shiny, you don't have to keep track of state yourself at all.
If you decide to give it a try and have trouble, please email me (email in profile) or drop by the Discord (https://discord.gg/yMGCamUMnS).
This seems to mainly be useful for spinning up quick and dirty internal tools.
But for that use-case, isn't it easier to use something visual and established like Retool (https://retool.com/) or that generates nice react code, like MUI Toolpad (https://mui.com/toolpad/)?
> Beyond Python and React ... Implementing frontends for other platforms like mobile ...
Shameless plug: I built a mobile version of this: https://www.applin.dev
I was looking at this space and nicegui seemed like the best ootb experience.
https://nicegui.io/
I'm under the impression that you work for a company that sells services related to FastAPI? https://github.com/Intility/fastapi-azure-auth
I maintain an open source library in my spare time for free, that you are welcome to ignore if you find better alternatives.
Ah! A real criticism of FE development, I agree with your problem statement.
When you jump into the world of single-page applications, things get complex pretty quickly, because the use case for needing an SPA pushes the web app into a full desktop application.
Ultimately, for a highly interactive and dynamic "desktop-class" user experience, there is added complexity. I think that's why so much movement within the FE world has moved away from "SPA for everything" and into these mixed dynamic apps. Islands, React Server Components, NextJS, they all help create a middleground between a document-based website with no dynamic elements with a full blown desktop app experience. They all have real tradeoffs, in particular adding an entirely new backend service to serve the front end.
For many projects, react + react-query is probably enough.
Having said that, my argument from https://bower.sh/dogma-of-restful-api still stands: when you build an API that is RESTful (1:1 mapping between endpoint and entity) you are unknowingly pushing the complexity of data synchronization to the FE, which requires a well thought out ETL pipeline.
This probably doesn't help my case but I've been building a simplified middle-layer for react to bridge the gap between react-query and full blown SPA: https://starfx.bower.sh