When using Apollo Execution plugin for server, wha...

# apollo-kotlin

[Joel Denke]

When using Apollo Execution plugin for server, whats the correct way of injecting dependencies into it, is it to use ExecutionContext like this?
https://github.com/paug/AndroidMakersBackend/blob/main/service/src/main/kotlin/androidmakers/service/Main.kt

private fun ApplicationCall.context(uid: String?): ExecutionContext {
    return AuthenticationContext(uid) + DatastoreContext(datastore) + CacheControlContext()
}

Will I then be able to get first parameter in my class methods that using @GraphQLQuery?
Or do I need some kind of singleton holding all deps?
I am trying to use Ktor server DI library, but I dont mind change to something else. Trying to structure my Apollo code better.

[mbonnin]

Either works. ExecutionContext is available on each an every field/resolver, it will go down your tree.

[mbonnin]

You can also configure your ExecutableSchemaBuilder with a lambda for the root Query and Mutation types and pass arguments there. Those will only be available at the root

[mbonnin]

1. is more flexible
2. is more typesafe

[Joel Denke]

Wait what configure schema builder, how would I do that?

[Joel Denke]

Will it work like this if provide execution context?

@GraphQLQuery
class Query {

    fun skills(executionContext: ExecutionContext): List<Skill> {
        return executionContext.firestore().document()
    }
}

Where I need to send in FirestoreCOntext and create extension firestore?

[Joel Denke]

Also not really like this as it kind of going against using DI isch. Maybe better send in DependencyRegistry as executionContext so I can always get any dep in all query/mutation classes?

[mbonnin]

1.

@GraphQLQuery
class RootQuery { 
  fun rootFields(executionContext: ExeuctionContext) {
    // retrieve your context here
  }
}

// later
val executableSchema = ServiceExecutableSchemaBuilder().build()
    apolloModule(executableSchema, executionContext =  {
      MyExecutionContext(foobar)
    })

2.

@GraphQLQuery
class RootQuery(val context: MyArguments) {
  // root field go here
}

// later
val executableSchema = ServiceExecutableSchemaBuilder().build()
      .queryRoot {
        RootQuery(myArguments)
      }
      .build()

[mbonnin]

ExecutionContext works like CoroutinesContext, it's a Map-ish API

[Joel Denke]

Ah ok so overloading queryRoot that ServiceExecutableSchemaBuilder already put? How does that work if having multiple Query classes, or can only have one?

[mbonnin]

You can only have one root query class

[Joel Denke]

Yes, I did notice the key and plus operator same as CorotiteContext, nice 🙂 Just very auto magic these things hard to grasp D

[mbonnin]

As there can be only one GraphQL query type

[Joel Denke]

Right, yeah I think I prefer expose the DependencyRegistry as Context, semi similar I think how Koin doing in Compose I think 😛

[Joel Denke]

Not very nice doing so, but kind of fine I guess 😛

[mbonnin]

LGTM!

[Joel Denke]

As only one root class should be fine performance wise doing so I guess, provide executionContext with DI tree 😛

[Joel Denke]

so I guess executionContext = { DiContext(Application.dependencies) + AuthContext} etc, where can send in AuthContext into mutations in Apollo require logged in user etc.