Graphql-go: Using SDL for schema?

[jblevins1991]

I am not sure about anybody else, but I don't see any support for writing all schema using SDL in a file and then importing the schema into GraphQL from the file. Is this a feature or a future-feature? I don't see many respectable businesses being okay with wasting precious time coding every type, input, interface, mutation, and query the long way over SDL.

EDIT: However, if this does not exist. I will be more than happy to build something with graphql-go that does accomplish this.

[tonyghita]

Hey @jblevins1991, this is already possible. Is there some API you would prefer to be a part of this package to make it easier? This is something I've been considering making part of the library for ease-of-use.

[pavelnikolov]

@jblevins1991, @tonyghita can you guys give some examples?

[zhukaiqiang]

Very much looking forward to this feature

[pavelnikolov]

How do you imagine this feature? Using some kind of generation tool? @zhukaiqiang how do you imagine this SDL?

[jblevins1991]

Sorry, have been vacant from the go community for a while. I would like to see some form of schema generation tool that takes one or more schema files and generates the schema for developers. I don't see much value in cranking out schema by hand, as it can take hundreds of hours to finish. I think those hours would be better allocated to creating a tool everyone can use to save time.

[pavelnikolov]

How would you like this generation tool to work? Do you want to use GraphQL schema as input and want the output to be corresponding Golang structs that can be used as resolvers out of the box?

[jblevins1991]

I think that would be the most natural way of doing it. I would like to help out with this.

[jblevins1991]

I started working on a cli tool for this. So far I have determined that a configuration file is needed at the root of the project. This is where you can define the location of datamodels that will be used to generate schema and an output path to generate the schema at. I have written code to open the config file and save its details in a struct. I wrote some validation code for the .graphql file extension for all datamodels. Now I am on to the parser.

The datamodel files will be parsed one by one. Line by line, so if there is an error, I can provide the line number. I will be developing the parser to go strictly by the graphql document spec this weekend.

[jblevins1991]

I have a lot of work done today on this. I'm hoping by the weekend I have the parser finished and then the only code required would be the code that actually outputs the schema and resolvers. I'm still fairly new to golang and would love someone to review my code and tell me ways to make this better once I have the first working draft of it finished.

[pavelnikolov]

@jblevins1991 I think that you have to start with a .graphql file and it should contain a schema. Schema-first seems to be that path of least resistance. This way the whole thing can even be started by a front-end developer. Learning a separate SDL seems like an overkill. On the other side, GraphQL schema is something that both front-end and back-end developers will be familiar with. So my suggestion would be, instead of working with SDL and configuration file, to think about a CLI that accepts flags. One for input .graphql file and one for output folder. If the output folder is not provided it can write the files to the same folder as the input file.

[jblevins1991]

@pavelnikolov That makes sense. I like the idea of a config file that clearly states what the inputs and outputs are for new hires/new contributers of a project, but we should have a command like graphql-schema-gen --datamodels data.graphql --output /schema. That would ignore the config code and then graphql-schema-gen would look for the config file.

[pavelnikolov]

@jblevins1991 let's not mix configuration with documentation. The CLI can always have --help flag, just like any unix tool, and anyone can read more detailed documentation. Also, if used with incorrect flags, proper validation/error messages should be presented to the user. Thew fewer moving components the better. Also, ideally, we should stick to the standard library only.

[zhukaiqiang]

I hope to get a better design than the 99designs/gqlgen project. The configuration file driven way of 99designs/gqlgen is much more complicated. I'm almost full of configuration files

[pavelnikolov]

I don’t want to compare or compete with other projects. Ideally, the design should focus on simplicity and ease of use. I would like to avoid configuration files and external dependencies if possible.
The CLI tool can allow for customization but should have reasonable defaults.

[jblevins1991]

That makes sense.

I have the command code finished. It turned out working as a command like schema-generator -d schema.graphql -o schema generate, do you think those should be the default values?

[pavelnikolov]

Yes, something like that. What I meant by customizations was things like schema options, for example, use field resolvers etc. All schema options are opt-in.

[pavelnikolov]

Could you raise a PR with the command? I'd be happy to give you early feedback. It doesn't need to be fully working. Maybe we need to create a separate repo for the CLI command 🤔

[jblevins1991]

I think a separate repo is more appropriate.

I am slowly working through the growing pains of go and procedural programming at the same time. So I have small chunks of what I hope is good code. Is there a medium of communication that we can talk on? I would like you to do a code review of the bits and pieces I have and give me advice and direction on how to put the pieces together.

[cpunekar]

Is there a way to have schema.graphql in a different folder and import that folder as of today?

[pavelnikolov]

@cpunekar at the time of writing this, the library expects a schema (regardless of where you load it from, the library doesn't work with files/folders and probably never will).