Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request and Response standards #1039

Open
dave42w opened this issue Nov 19, 2024 · 3 comments
Open

Request and Response standards #1039

dave42w opened this issue Nov 19, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@dave42w
Copy link
Contributor

dave42w commented Nov 19, 2024

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?

@dave42w dave42w added the enhancement New feature or request label Nov 19, 2024
@sansyrox
Copy link
Member

Hey @dave42w 👋

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.

@sansyrox
Copy link
Member

Some thoughts about why not ASGI (#27 )

@dave42w
Copy link
Contributor Author

dave42w commented Nov 21, 2024

Hi,

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants