Runtime Schema Updates and Subscription Types

[christyjacob4]

I have 2 questions

1. Schema Updation
   We have a use case where some of our database tables can change over time. As a side effect the number and data type enclosed in the columns can change over time. What is the recommended way to update the schema in the most efficient way?

2. Subscriptions
   I went through the documentation and only found a few references to GraphQL subscriptions. Is there any example I could follow ?

[mfn]

1. We have a use case where some of our database tables can change over time. As a side effect the number and data type enclosed in the columns can change over time. What is the recommended way to update the schema in the most efficient way?

GraphQL is not related to any DB, so there's no single "most efficient way".

Unless you directly pass objects from somewhere and entirely rely on the default resolver, you just write custom resolve methods all the way. That is how you stay consistent within your GraphQL schema if you don't want your storage schema changes to be reflected there (that is: if you the storage schemas can be transformed in a way they don't change for your GraphQL schema in the first place).

HTH

[christyjacob4]

Let me elaborate on my use case. I'm trying to build a graphQL API for our REST API. We have the following services

1. account
2. users
3. database
4. storage
5. functions
6. locale
7. avatars

For the most part, the response models of these endpoints are well defined so I can model a graphQL query for each of these services. The problem arises with the database service. We have collections ( each of which has a different structure and users can create new collections as well using the dashboard. Something like Firebase) So this is what I meant by database tables can change over time. Users are free to create new collections with different structures based on their app's needs.

Let's say the users create a collection called Movies represented by

type Movie = {
    title: string;
    year: number;
    published: boolean;
    director: string;
    actors: string[];
}

This information is not available to me at compile time. This happens dynamically at run time when the users create this collection. So at this point in time , I have already constructed a graphQL schema for all the other services I have mentioned above that have predictable response types.

I would like to define the following queries for any collection that is created at runtime

query getMovie( collectionId: string, movieId: string )
query getMovies (collectionId: string)
mutation updateMovie(collectionId:string, movieId: string, movie: MovieType) 
mutation addMovie(collectionId: string, movie: MovieType)
mutation deleteMovie(collectionId: string, movieId: string)

I want to understand how I can dynamically create these Types and add this to my existing schema ( one created during build time) so that all these queries are available to me in my GraplQL explorer.

[christyjacob4]

This is similar to how https://hasura.io/ does it , but I wanted help specifically from the graphQL-php community , if anyone has done it before or how I can achieve this

[vladar]

There are not that many options:

1. Model those collections as JSON
2. Create the full schema after user constructs their collections (so that user-specific types become a part of the schema)
3. Use SchemaExtender and add user-specific types to your existing schema

Keep in mind that options 2 and 3 are basically the same as SchemaExtender creates a new schema instance anyway.

[christyjacob4]

Sorry for the delayed response.

I can't use option 1 (as I mentioned their structure cannot be predicted beforehand)

I can't use 2 either because I would want the other GraphQL queries for the other services to be available even before the user creates any collection.

The third option with the schema extender looks really promising. Could you point me to some example usages of the SchemaExtender ?

[christyjacob4]

I did take a look at some of the test files

graphql-php/tests/Utils/SchemaExtenderTest.php

Line 223 in ba9e3e2

$extendedSchema = SchemaExtender::extend($this->testSchema, $ast, $options);

All these examples involve passing a SDL string to the parser.
In my case where I am dynamically generating the schema , I prefer using this syntax which is much more convenient

$schema = new GraphQL\Type\Schema([
  'query' => $MyAppQueryRootType,
  'mutation' => $MyAppMutationRootType,
]);

Is there a way for the parser to accept a query / mutation object instead of an SDL string ?

[christyjacob4]

@vladar @spawnia Could you help me with the query ? Thanks 😄