Automatic construction

[JonathanFraser]

I have a schema which returns an expanded object, let's say User.

type Foo {
   user User
   somefield Int
}

type User {
  id ID
  name String 
  email String 
}

Now the underlying data in the parent is just a user_id but I want to expose queried fields in user.

As near as I can tell I have two options:
the first is to manually attach the fields

user = ObjectType("User")

@user.field("id")
def id(par,_*):
  return par

@user.field("email")
def email(par,info):
  return get_db_from_info(info).query_user_email(par)

the second is to use a class but construct it in the parent

foo = ObjectType("Foo")

@foo.field("user")
def id(par,info):
  return User(par.user,get_db_from_info(info))

where the user class does the appropriate queries.

But it really begs the question if there is a way to get ariadne to run an object constructor by default when attempting to resolve a given type and then fall back to the default resolvers.

something like

user = ObjectType("User").constructor(lambda x:User(x,dbconnection))

[pylipp]

I'm not entirely sure what you're trying to achieve. It comes to my mind that

1. using your first approach is more generic, since it will apply for any fields that return a User type.
2. you might want to look into ORMs. E.g. peewee returns a Python object on a query, and its attributes can be nicely accessed by ariadne's default resolver. But also with more low-level DB drivers which return dicts as query results the default resolver works.

[JonathanFraser]

you might want to look into ORMs.

1. If I have to rewrite my entire data model to bolt an API on top, something is seriously wrong.
2. ORMs can sometimes cause as many issue as they solve with their assumptions
3. I'm using a document store which makes ORMs that much less useful.

But also with more low-level DB drivers which return dicts as query results the default resolver works.

I have those, but what I'm looking for is a way to inject that between the field resolvers at the type level.

[rafalp]

To be honest, both of those approaches seem wrong here. Why can't resolver for Foo.user return the User representation specific to your business logic (eg. Django model) and then resolvers on User fields resolve fields in schema to model fields?

[JonathanFraser]

Why can't resolver for Foo.user return the User representation specific to your business logic (eg. Django model)

Because I would have to put that into each and every field resolver that returns that User type. Either explicitly with code, or implicitly with a data-layer abstraction like an ORM.

Ariadne is nicely function and having explicit mappings make for good code. It seems a little odd to explicitly define every field but implicitly define the data loader between them (and provide no mechanism to make it explicit). What I'm looking for is a way to define "type resolver" that sits in between field resolvers. Where I can inject some resolution code for every instance of a type regardless of what field gets called on it. This way I can be explicit about how my business layer mapping is defined.

[rafalp]

Because I would have to put that into each and every field resolver that returns that User type. Either explicitly with code, or implicitly with a data-layer abstraction like an ORM.

This is the GraphQL way. It's perfectly normal to have multiple resolvers with same logic (eg. one-line dataloader call to return User with given ID). Resolvers and python modules that look like this:

@forum_thread.field("starter")
def resolve_thread_starter(thread, info):
    return load_user(info.context, thread.starter_id)


@forum_thread.field("lastPoster")
def resolve_thread_last_poster(thread, info):
    return load_user(info.context, thread.last_poster_id)

Above code is explicit dataloader call to retrieve User representation that resolvers on User type understand.

[JonathanFraser]

It is explicit, but its also somewhat repetitive. It also means that you either do some adhoc caching in context, or you are faced with multiple data lookups for a single object that is both in efficient or worse might be inconsistent.

I suppose what I'm looking for is technically available right now with some modest wiring. I think you would just need to run a visitor pattern that wraps every resolver that returns User and enriches the data with your business logic.

[rafalp]

I think you would just need to run a visitor pattern that wraps every resolver that returns User and enriches the data with your business logic.

That's best way to go about it.

It also means that you either do some adhoc caching in context

Yup, dataloaders usually cache already-loaded data in the context, but I would hardly call that a downside ;)