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

Make Extension system async. #710

Open
greemo opened this issue Oct 27, 2021 · 9 comments
Open

Make Extension system async. #710

greemo opened this issue Oct 27, 2021 · 9 comments
Labels
enhancement New feature or request to do

Comments

@greemo
Copy link

greemo commented Oct 27, 2021

Calls to request_started and request_finished in ExtensionManager should be made with await..

I can implement this if there is no objection..

@rafalp
Copy link
Contributor

rafalp commented Nov 19, 2021

Is this to run blocking IO like api calls or database queries?

@greemo
Copy link
Author

greemo commented Nov 19, 2021 via email

@rafalp
Copy link
Contributor

rafalp commented Nov 19, 2021

GraphQL extensions shouldn't manage database connection. This should happen outside of Ariadne, eg. in Starlette's startup and shutdown methods.

@greemo
Copy link
Author

greemo commented Nov 23, 2021

I'm not talking about the connection, I'm talking about the session. We should have a new session every request so the cache is flushed per request.

@rafalp
Copy link
Contributor

rafalp commented Nov 23, 2021

This should be implemented as ASGI middleware and not GraphQL extension. GraphQL extensions should be used for things that really really are associated with query execution process itself, and nothing else.

@greemo
Copy link
Author

greemo commented Nov 25, 2021

Hmm, I see querying the DB as being definitely related to executing a query. It is a bit strange that I need to bury by db session in the Request object, accessing it via context["request"].state.dbsession, but I could always use a context generator to make it available directly in the context.

I think as Ariadne is supposed to be an async platform, the extension system should also be async, but feel free to close it if having them as async feels wrong to you...

@rafalp
Copy link
Contributor

rafalp commented Dec 2, 2021

I'm not arguing against making extensions system async, I can see a point in that (which is why issue is left open). I'm arguing against using them for managing database sessions.

Long story short, we've never considered Ariadne a web framework. It's ASGI/WSGI apps work without one because it makes it very easy to get started with your own GraphQL API for learning/prototyping and also for running simple API's in production.

However we are seeing more and more people trying to use its extension points (like extension system, connect/disconnect events) to shove in extra logic there that could as easily be placed into lifecycle methods of Starlette or ASGI middleware. Trying to shove connections/auth/session management leads to "it almost works but if only you could do this little change" discussions like this one (or one in websocket on connect/disconenct hooks) because those are designed for different use cases and there's no guarantee those use-cases will overlap with yours.

You can heat up a food in dishwasher, but your kitchen likely supports better ways to do that sort of deal. ;)

@rafalp rafalp added the enhancement New feature or request label Dec 2, 2021
@dacevedo12
Copy link

I'd find this useful to read stuff from the request in starlette, as the request.json() method is async

Or maybe pass the operation info to the extension so one could easily implement performance tracking extensions.
I'm currently working around this limtiation by setting what I need in a custom context value, then using it in the extension.

@rafalp
Copy link
Contributor

rafalp commented Jul 21, 2023

We could add a check in Ariadne's ASGI server for request_started and request_finished to see if their result isawaitable and await them if thats the case. That way both sync and async would be supported.

@rafalp rafalp added the roadmap Feature that we want to have included label Jul 21, 2023
@TMuszczekk TMuszczekk added to do and removed roadmap Feature that we want to have included labels Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request to do
Projects
None yet
Development

No branches or pull requests

4 participants