The application in the demo video left me with a few questions
1. Why does it use two requests with OPTIONS and POST methods instead of a single GET? Is this to reduce the amount/complexity of error handling logic in the generated application?
2. Why use a POST http request to get the sales data. I would have expected the route to use GET in this situation?
The use of a single POST request (the underlying logic behind the @app.task decorator) is meant to simplify things, especially for users who aren’t familiar with FastAPI. It abstracts away routing and request handling so you can focus on writing business logic without worrying about HTTP methods, URL paths, or response formatting.
That said, since Davia is built on top of FastAPI, you can absolutely define and use your own endpoints if you prefer.
With Davia, you build on FastAPI and React best practices.
Streamlit and Gradio rely on fixed components, which makes it hard to adapt the UI to your specific use case. Davia lets you define any interface you need.
Streamlit also has production limitations like authentication, layout control, and API integration. And for AI use cases, it reruns the whole script on every input, making state management difficult. Davia supports real-time streaming and proper stateful interactions.
1. Why does it use two requests with OPTIONS and POST methods instead of a single GET? Is this to reduce the amount/complexity of error handling logic in the generated application?
2. Why use a POST http request to get the sales data. I would have expected the route to use GET in this situation?
Honestly it would be super useful to have this as a standalone feature , that can run native in cloud, kind of like an edge function service