Apollo Client with Arbitrary GraphQL Schemas: Part 2

We now implement our example that consumes an arbitrary GraphQL schema.

This article is part of a two-part series starting with Apollo Client with Arbitrary GraphQL Schemas: Part 1.

GraphQL Introspection

In order to create an application that adapts to an arbitrary GraphQL schema, we need to be able to read that schema at runtime.

It’s often useful to ask a GraphQL schema for information about what queries it supports. GraphQL allows us to do so using the introspection system!

— GraphQL — Introspection

For example, using the graphical tool, we can query for all the types, including our Todo types:

{
  __schema {
    types {
      name
    }
  }
}

We can also query the Todo type to obtain its shape:

{
  __type(name: "Todo") {
    fields {
      name
      type {
         kind
         ofType {
           name
         }
       }
     }
   }
}

Limits of GraphQL Introspection

While GraphQL introspection is powerful, it does not solve a couple of problems:

• From the types query, we cannot immediately tell which are the important (from a business logic perspective) types, e.g., Todo
• Starting from a type, e.g., Todo, we cannot determine which are the related queries (say for doing CRUD operations)

Essentially GraphQL is purposefully flexible in its schema; both a benefit and a problem.

note: This is in contrast to ODATA which is much more rigid.

This being said, if we know that we are interacting with a Graphile GraphQL implementation with a certain type (Todo), we can know the related queries, e.g., allTodos, createTodo, and deleteTodo.

note: Technically, in addition to knowing the type (Todo), we need to need to know how to pluralize it (Todos).

A Somewhat Adaptive Example

This example is pre-configured to work with a known Graphile GraphQL endpoint with a known type (Todo / Todos). Using GraphQL introspection it will determine the shape of a Todo and dynamically provide a CRUD application for it.

note: To keep things simple for now, the example assumes that we also created the supporting PostgreSQL table using an auto-incrementing integer primary key (id) with all the additional fields being text.

For example, we can use the following SQL to add a new text field (test) to a Todo.

ALTER TABLE app_public.todos ADD test text;

note: Our Graphine server is configured to adapt to PostgreSQL schema changes.

The example will dynamically provide the additional inputs and outputs for the new test field.

The Implementation

The implementation, also available for download (master branch), primarily consists of:

• src/components/Entities/index.tsx: Provided the type name, e.g., Todo, performs the GraphQL introspection query to determine the shape (fields) of the type
• src/components/Entities/EntitiesWithFields/index.tsx: Provided the fields (and related properties) uses react-apollo Query and Mutation components to wrap GraphQL API queries
• src/components/Entities/EntitiesWithFields/EntitiesWithFieldsCreate/index.tsx: Container (controller) component for form to create entities
• src/components/Entities/EntitiesWithFields/EntitiesWithFieldsCreate/EntitiesWithFieldsCreateView.tsx: Presentation (view) component for form to create entities
• src/components/Entities/EntitiesWithFields/EntitiesWIthFieldsEntity.tsx: Render an entity listing
• src/components/FKTextInput.tsx: Render a form input field

Observations:

• While the previous example used custom code to manage the form, this example introduces the Formik form management library
• In hindsight, I realized that it was redundant to pass both the fields and all the related properties to the EntitiesWithFields component; instead it would have been more sensible to simply pass the fields and generate the necessary values in EntitiesWithFields

Wrap Up

Interestingly enough, this work was theoretically easier than I thought it would be (GraphQL introspection being the key) and at the same time a more complex implementation than I expected (TypeScript adds a layer of complexity).