Creating GraphQL-Apps using Go

A few days ago i published my first Medium story, where i described why i would prefer Go and GraphQL over Java and REST. Well, actually i presented a completly stack based around Go, GraphQL and CockroachDB.

In the meantime, i created an example project available on GitHub. At the moment, it does not use CockroachDB, but i will add the support later. Its an example to show how, you easy it is to build a structured Go application around GraphQL.

Advantages of GraphQL and gqlgen

GraphQL can make life a lot easier. As mentioned in my last Article, it provides schema-files. Inside these files, you describe your API and your models. The syntax can be read online.

gqlgen is a tool build on top of these schemas. It takes one or more schema-files and generates Go-Code from it. You just have to implement so-called resolvers. Resolvers are described in interfaces in the so-called server- or exec-file.

All you have to do is creating a HTTP-Handler combining the generated GraphQL-Server and your implemtened resolvers. This could look like this:

Example on how easy it is to start a GraphQL-Server in Go generated by gqlgen

When you first run GraphQL, it will also generate the example resolver file. However, it does not re-generate it in case you made changes to the described queries, mutations or subscriptions. Any changes and additions needs to be added by yourself. You can just copy the methods-signature from the re-generated server file.

Project Structure & Core Concepts

First of all, i want to talk about the projects structure. The code is organized in multiple directories:

• cmd/ holding the main package and the applications entrypoint
• graphql/ holding all files generated by gqlgen as well as the implementation of our resolvers
• model/ holding all data-models used by our application
• repository/ holding layers for accessing data-repositores, e.g. Databases or streaming-services
• service/ holding layers for implementing business-logic such as creating new Articles from an object representing the article creation request

The separation in repositories and services is something i adopted from working with SpringBoot for the last years. They have taken it from the principles of Domain Driven Design.

The separation of repositores, services and GraphQL-resolvers will layer our application like in the example above. Every layer has strictly definide responsibilities.

Every single layer has a strictly defined responsibility and some functions resulting from it. You can read the exact tasks of the individual layers inside the projects README.

Principles using this Setup

To get the full range of advantages using this structure, you’ll need to follow some simple principles:

1. Always define the functions a repository or service should have in an interface — This enables changing the specific implementation depending on the use case, when used with dependecy injection. Would allow you to test the service layer by passing a testing-only repository without the need of an existing database
2. Don’t let your models live in the generated model-files — Whenenver the models get regenerated (because you added a new or changed an existing-one) there no garantuee for your hand-made edits to survive. Always extract generated models into your own models/ directory.
3. Never follow this guidelines to exactly — This is just an example of how you could struct an GraphQL-Application. It does not mean that this example is always matching your needs. Take it as an suggestion of how you could possibly start your project.

Feedback & Contributing

I love feedback! If you have any question or suggestions for this example-project, you can get easily in touch with me using Twitter, GitHub or Medium. Of course, i’m happy for every contribution made to this example project. If you want to add or improve something, open a PR.

Thanks for reading! I hope to see you soon :-)