You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My thinking is that there is a lot of well-proven and thorough work there and it would make migrating web apps from the most popular web frameworks to Robyn much easier.
I'd do this by making our request a subclass of the Werkzeug request. That way we can provide both our existing interface and the Werkzeug one to our endpoints. Eventually we can deprecate our version and encourage people to move towards the Werkzeug interface.
Thoughts?
The text was updated successfully, but these errors were encountered:
Robyn chooses to move away from ASGI/WSGI on purpose. It gives us more control over our sever implementation.
We can implement the features from the Request class that are missing in Robyn's Request class. But Robyn's request class should not be a subclass of Werkzeug or Uvicorn.
I wasn't thinking of anything wsgi (I didn't think the Wurkzeug) wrappers included any of that (but installing the package might).
I also get that maybe they don't include any async methods (might be handy for very large request bodies).
So how about we try for duck typing compatibility (can look at some asgi ones as well). Then switching to Robyn request should only require importing our request instead of the Wurkzeug one.
I figure that by now they have a good mapping of the whole http specification.
I'm wondering if we could migrate to using a "standard" or at least very common model for requests and responses.
What I'm thinking is using the wrappers from Werkzeug https://werkzeug.palletsprojects.com/en/stable/wrappers/#werkzeug.wrappers.Request as Flask and many other projects do.
My thinking is that there is a lot of well-proven and thorough work there and it would make migrating web apps from the most popular web frameworks to Robyn much easier.
I'd do this by making our request a subclass of the Werkzeug request. That way we can provide both our existing interface and the Werkzeug one to our endpoints. Eventually we can deprecate our version and encourage people to move towards the Werkzeug interface.
Thoughts?
The text was updated successfully, but these errors were encountered: