2

I have an Elixir Umbrella app, with Phoenix, Absinthe (graphQL). In AppWeb, my AppWeb.Router routes requests, handling /graphql with Absinthe.Plug and using MyApp.Schema.

In AppWeb.Schema, I import objects from numerous different schemas in different OTP applications using import_types. I will use Users as an example.

The Users.Schema has objects and fields, where eventually will resolve &Resolvers.resolve_x/2

I know that Phoenix is starting a new process on each request, the hexdocs Absinthe.Schema states In Absinthe 1.5 schemas are built using the same process by which queries are executed. Does that mean that each new process created by a request by phoenix, communicates with a single schema (AppWeb.Schema) process? If so, won't that create a bottleneck? If not, isn't that a lot of code (all resolvers and relevant functions from all OTP apps) to be transferred to the new schema process spawned every-time?

alexexchanges
  • 3,252
  • 4
  • 17
  • 38

1 Answers1

0

In Absinthe 1.5 schemas are built using the same process by which queries are executed.

This doesn't refer to a BEAM process but rather that in Absinthe 1.5 schema's are built using a similar method as to how queries are resolved.

There are two ways to build schema's in Absinthe.

  1. Using the macro-based DSL, this is what was already available in Absinthe 1.4
  2. Using the Graphql Schema Definition Language (SDL), in this case Absinthe parses the SDL and builds a schema from it, resolvers etc. can be attached using the hydration constructs.

After either of these ways to build a schema, its blueprint (AST of the schema) goes through a pipeline of phases in which e.g. validation takes place. This is what is referred to by 'same process`, as a graphql document in Absinthe also follows the route of graphl document -> parse to AST blueprint -> validation -> other phases.

Be default the compilation of the schema still happens at compile time, so no extra processes are spawned for a request.

Maarten van Vliet
  • 572
  • 7
  • 12