Rafał Pitoń

Yup! That would be helpful, thanks!

Note to self: We also want to extract parts of GraphQLMiddleware into reusable utility functions so we can share some view logic between Ariadne and other libs (eg. Django views)....

This could even be an util called after `make_executable_schema`, eg: ``` schema = make_executable_schema(...) validate_root_resolvers_are_set(schema) ``` That way it'll be useful even after people do something to the schema after...

@patrys This works as intended, but internal feedback I've gathered so far is negative - people coming from Django expect to use Starlette's middleware to set things on `request`, and...

Ah, so those are available via `request.scope`? All-right then! I'll keep this issue open to see if it makes sense to mention this in our docs sometime when I'll be...

Middlewares should use `request.scope` instead of `request` to store the data to be available from within the Ariadne. When people use Starlette's [`AuthenticationMiddleware`](https://www.starlette.io/authentication/), they follow the docs and use `info.context["request"].user`...

This is same thing. No middleware-specific attribute of `request` will work within the resolver. You need to use `info.context["request"].scope["auth"]` for this. ASGI spec defines `scope` as value that should be...

Looking good so far. We'll also need tests suite for this and entry in `CHANGELOG.md`

This work is currently on hold, but PR that would continue this work to completion (eg. rebase on master, optimize, add tests and error handling) is welcome.

Is there a reason you can't do this by pulling JSON from request custom `context_value` callable? By the point it's called by Ariadne JSON payload was already validated.