GraphQL support

[patrick91]

Hi there! I'm the maintainer of Strawberry GraphQL, I just saw the talk about autometrics at PyCon UK (thanks @brettimus) and I was wondering if there could be a place for adding support for GraphQL queries.

Here's an example of GraphQL API using Strawberry:

import strawberry

@strawberry.type
class User:
    name: str
    age: int

@strawberry.type
class Query:
    @strawberry.field
    def user(self) -> User:
        return User(name="Patrick", age=100)

schema = strawberry.Schema(query=Query)

and here's a query:

query GetUser {
  user {
    name
    age
  }
}

This query would (in a simplified way) result to 3 function calls:

-  user = Query.user()
    ├─ getattr(user, "name")
    ├─ getattr(user, "age")

I wonder if there's maybe a place for automatically instrumenting GraphQL queries (instead of instrumenting the resolvers directly?), or maybe we can add instrumenting for top level fields (like the user field).

[brettimus]

thanks for posting, patrick! it was nice chatting with you after the talk

i think there's something here, especially regarding your design decision to define schemas in code. something feels philosophically similar to how we handle certain logic.

as for the current state of the python library, i tried seeing how it would play with strawberry (code here). it was a fun experiment! i used the strawberry fastapi integration.

i was able to decorate a resolver when it was defined as a method on the class, but we'd need to think through how to support the syntax of strawberry.field(resolver=get_books).

the only thing that came to mind right now, aside from decorating the resolver itself before it was passed to strawberry.field, was something like strawberry.field(resolver=get_books, instrumentation=autometrics), which i suppose would just be sugar for wrapping the resolver in instrumentation logic like autometrics.

@strawberry.type
class Query:
    books: typing.List[Book] = strawberry.field(resolver=get_books)

    # NOTE - `@autometrics` broke unless it was the first decorator on top of the resolver
   #                i think this is because @strawberry.field does not return a function that can in turn be decorated
    #
    @strawberry.field
    @autometrics
    def last_book(self) -> Book:
        return get_books()[-1]

as for wrapping subcalls to, for instance, getattr, that could be trickier. if that feels like it would be valuable, i'm down to discuss this in more depth, but yeah. there might be a dragon or two or three 🐉

[brettimus]

ah okay i just got to the part of the strawberry docs on extensions, i see that'd likely be a better way to take a crack at this!

[patrick91]

yes, extensions are the way to go, sorry I should have mentioned this 😊

I still wonder if there could be a way to add per query goals (automated), but maybe that's too out of scope

[brettimus]

yeah so in this case, my feeling is that any extension would likely be a separate implementation than our decorator, and instead it would just produce "autometrics-compatible" data, which could leverage our pre-written queries and such.

as for per-query goals, i think that would be possible! we define objectives simply through additional labels on the underlying metric in prometheus. it'd be a tiny bit of a hack, but certain queries could just define their own objective.

it's an interesting application for certain

[brettimus]

by the way, the way you handle integrations with frameworks inspired me to file an issue on our python repo! autometrics-dev/autometrics-py#91

[patrick91]

that's cool! my only issue with that is having to maintain it, but in your case I guess it's not going to be a lot of code, so should be good!