Dynamic resolver as a middleware?

[vicary]

Use Case

Since the example of hosting Apollo Server on AWS Lambda, we are looking at the possibility of breaking every single resolver into their own lambda. Where it would be handy if we can provide a middleware instead of a per-type resolver for the defined schema.

Not sure if this is related to #2560, my use case is somewhat similar to the context function signature, with the requested operation as an argument.

Could this be a plugin?

TBH this is somehow one level lower than the current exposed options. Instead I think my proposed options should be the core, spinning off the built-in typeDefs and resolvers into an official plugin.

Workaround

I don't see a proper workaround except we copy the same function into every single resolver that matches the provided schema.

[sbrichardson]

I added some code on the related issue you mentioned to get to the dynamic schema. It may help
#2560 (comment)

[vicary]

@sbrichardson thanks for the reply.

Your sample code shows the possibility of a dynamic schema makeExecutableSchema({ typeDef }), while this issue is about a dynamic resolver makeExecutableSchema({ resolvers }) that depends on a schema.

In theory we could make this work by starting an internal introspection server, generating a resolvers object mapping based on all types queried, close the temporary server and starts the real one.

But this adds a huge overhead of boot time as a lambda function, quite opposing the reason we go serverless in the first place.

[martijnwalraven]

Breaking every single resolver into their own lambda seems like a pretty bad idea to be honest, because resolvers tend to be rather fine grained and the overhead of calling individual lambdas would be too large. You may want to look into Apollo Federation however, which allows you to break up your schema across services.