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
Should Router be a subclass of Starlette? #122
Comments
I was wondering something similar or maybe when we instantiate |
Not really, the What we should do tho, is make sure that router and app share the same fundamental API for routing. First pass on that means that stuff like this ought to just work. app = Router()
@app.route('/')
async def homepage(...):
... It's possible that we should hide away the lower-level Once we've got two properly matching interfaces, then it's clearer. It's also worth highlighting that you can submount |
Thank you @tomchristie -- just a brief addition. I have actually expressed this wrong, as by "subclass" I was actually thinking of a "subtype", i.e. -- exactly as you said -- that it would be useful if all ASGI apps in Starlette (routes, endpoints etc) shared the same interface. Perhaps that can be formalised in the form of some kind of ABC or mixin or something similar. Thank you for the great work! |
Right now,
Router
is simply an ASGI app, which means that it can be used as a top-level app; however, it can't benefit fromStarlette
-specific features such asdebug
, lifespan events or exception handlers.Would it make sense to make
Router
a subclass ofStarlette
? That way instead of:we can have
and keep all the advantages of
Starlette
.This is just a simplified example, of course.
The text was updated successfully, but these errors were encountered: