Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GraphQL: Pull up schema types #428

Closed
philippguertler opened this issue May 30, 2018 · 2 comments
Closed

GraphQL: Pull up schema types #428

philippguertler opened this issue May 30, 2018 · 2 comments
Assignees
Milestone

Comments

@philippguertler
Copy link
Contributor

philippguertler commented May 30, 2018

Description

Currently, the type for different schemas in GraphQL is differentiated in fields. So to query fields of a node, the query has to look like this:

{
  node(path: "/images") {
    uuid
    fields {
      ... on folder {
        name
      }
    }
  }
}

I recommend changing the GraphQL types, so that the query looks like this instead:

{
  node(path: "/images") {
    uuid
    ... on folder {
      fields {
          name
      }
    }
  }
}

The change was that the ... on folder was pulled up one level.

A common use case is to have different queries for different schemas. With this change, it would be very easy to create a fragment for each schema and use them in the node query. Here is an example:

{
  node(path: "/images") {
    uuid
    ... folder
    ... vehicleImage
  }
}

fragment folder on folder {
  fields {
    name
  }
}

fragment vehicleImage on vehicleImage {
  path
  fields {
    name
  }
}

As you can see, this leads to a nice and clean main query, and a fragment for each schema. Also this allows for schema fragments to query properties that are not fields, which is currently not possible.

Backend Implementation

We could have a common interface for Nodes which includes all common fields (uuid, path, creator, etc.)
For each schema we then create an implementation of that interface with the additional fields property.

API Implementation

Simply changing this would cause a breaking change. I see these ways to solve this:

  1. Just let it be a breaking change. This is maybe acceptable for Mesh 1.0
  2. Instead of breaking the existing API, add new types for the API (ex. NodeInterface, FolderNode, VehicleNode, etc.) and allow them to be queried in addition to the old types. Maybe we can deprecate the old API and later remove it.
  3. Make the new API available through another configuration (mesh.yml, GET-Parameter, different URL)
@rafacm
Copy link

rafacm commented Jun 1, 2018

  1. Just let it be a breaking change. This is maybe acceptable for Mesh 1.0

@philippguertler: you could (pre-)announce upcoming breaking changes in the Release Notes to prepare/warn users and see if anybody shouts before investing time and energy in options 2 & 3: https://getmesh.io/docs/beta/changelog.html

@Jotschi
Copy link
Contributor

Jotschi commented Jun 6, 2019

Change has been released with 0.35.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants