GraphQL associations.

[Hyperkid123]

I was asked by @gmcculloug if I could provide some summary of missing features in the catalog in order to fully leverage the GraphQL potential. I am going to start with the most important issues and follow up with minor ones.

Associations are not generated for the catalog API.

I know that @abellotti is aware of this since it was discussed before (RedHatInsights/catalog-api#316 (comment)). But I feel like it has to be mentioned because associations are basically the only reason why would you want to use GraphQL on the front-end. The ability to compose responses is priceless and the only reason why the adaption of GraphQL is so huge in front-end apps. Without associations, there is no point in using GraphQL.

Associations are only one-directional

Since associations do not work in Catalog, I will use sources as an example. Sources schema does generate associations, but they are not bi-directional, which significantly limits the composition of queries. I will refer to an outdated doc for sources. There might be some missing attributes or entities even, but the associations did not change. http://sources-graphql.surge.sh/sourcetype.doc.html

Let's take Source and SourceType an example. If I want to query all sources of a specific type, I can write a query like this:

query {
  source_types {
    name
    id
    sources {
      id
      name
    }
  }
}

This will return this data set:

{
  data: [{
    id: "1",
    name: "Source type name"
    sources: [{
      id: "1-1",
      name: "Source name"
    }, ...]
  }, ...]
}

Now, this is ok, it works just fine. The problem is if I want to do it the other way around. For example if I would get a task to create a detailed page for Source and on that page, I should also display data about the source type, I can't use GraphQL for it and I would have to create multiple queries. Association Source -> SourceType does not exist.

I would expect to be able to do this.

query {
  sources {
    name
    id
    source_type {
      id
      name
    }
  }
}

With result:

{
  data: [{
    id: "1-1",
    name: "Source name"
    sourceType: {
      id: "1",
      name: "Source type name"
    }
  }, ...]
}

The belongs to (from child to parent) association is actually much more common in UI than the other one. Detail screens in most of the cases contain data about its parents in the hierarchy. Source type in a Source, Networks in Vms, Source in a SubNet, etc. Drilling down is also useful, but if I had to choose between those two I would rather get to parent data because I know I will need them more often and most of the time, child data are being lazy-loaded/paginated/filtered anyway so I will have to use a separate request no matter what.

Missing pagination metadata

Although it is possible to paginate via GraphQL queries, it is not very helpful, because we do not get the count attribute. We don't really need the limit/offset attributes since we have them in UI, but the count attribute is a big one. Without it, we can't say what is the number of pages, what is the current page, if there is the next or previous page, what is the last page etc. You can get around that by doing second rest query to API which will return all the metadata and get the count attribute that way, but then there is no point in using pagination via GraphQL.

Filtering parent attribute via children attributes

Let's use VMS as an example. I will make up an attribute status which can have a value of error and ok.

Let's say we want all Sources where any child VM is in error state. That is not some ludicrous idea. Not possible at this moment.

Make the schema and resolvers extensible

If we could change the schema and resolvers, all the above could be resolved in the consumer app/library.

Static GraphQL schema available in UI when building the app.

I do not expect this to happen, but I feel like it is important to mention this. There is a lot of uses for the schema, not just on the back-end, but also on the front-end. One of them is very smart code-splitting and data pre-fetching.

The idea is to replace the following process.

1.	2.	3.	4.	5.	6.
fetch HTML template	fetch JS files	load JS files	first render of react component	make an API call	render the data

With library combination of React, GraphQL, and Relay, you can replace the above with following, jut by using them:

1.	2.	3.	4.
fetch HTML template	fetch JS Files	load JS files
		first render of react component
		make an API call
			render the data

This significantly reduces time to first render which has a noticeable difference in UX. I know this might not be something you would prioritize but for me, as a UI dev this is very important.

In order to do this, it is required to have the GraphQL schema available at build time.