Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for Schema Previews #45
@ItsMeWithTheFace and I figured out a way to autogenerate enums and input structs for schema previews by attaching custom media types to the headers.
We have not yet figured out a stable way of automatically fetching the media types (
I will add a separate package
Thanks for looking into this, it's a good start.
One of the most difficult decisions we'll need to make before a change like this can be merged is where to place the preview schema types. Should they go into the same package? A new package? Several new packages? We can come back to this later.
I suggest don't worry about making code changes until we agree on the plan.
I noticed at https://developer.github.com/v4/public_schema/ GitHub offers the file https://developer.github.com/v4/public_schema/schema.public.graphql. That file has a different format, I'm not completely sure which format it is. But it includes information about all previews, and what identifiers belong to what preview. E.g.:
Perhaps we should use that file to generate from, then we can know which types/fields belong to a preview, and add documentation saying that a given Go identifier is a part of a preview.
If that's possible, it may actually make sense to put all the preview types into the main package. But still need to think more about that.
Would you like to investigate (perhaps on a different branch/PR) what it'd take to generate via that file instead?
The https://developer.github.com/v4/public_schema/schema.public.graphql file is in GraphQL SDL format.
I'm still new to Go and GraphQL so creating a transpiler for SDL -> Go lang is definitely a challenge that I'd like to take on, but will take me a long time.
As we require this functionality ASAP, is it cool if I create a parser that retrieves the preview media types (
No worries. You also don't have to work on it unless/until you want to.
It is cool, but I won't be able to merge it into this repository because I'm looking to find a long-term solution here. I suggest you use a fork until this issue is resolved upstream. That way, you can solve your immediate needs without being blocked. This repo doesn't change much, so there shouldn't be much of a maintenance overhead.