You should use Gqlgen (Maybe)

December 29, 2018 ยท 2 minute read

What is Graphql?

Graphql is a query language that has taken the frontend development scene by storm. It provides a great way to expose data to the frontend that allows the frontend developers to request exactly the data they need, no more over fetching, or under fetching (at least in theory). It isn’t a panacea, and shouldn’t be overhyped. It does though add another tool in the tool belt that can improve the frontend development experience.

What is Gqlgen?

GQLGen is a library for Go for implementing graphql apis. It utilizes code generation to provide a strongly typed, robust experience. There are several other competing libraries, but gqlgen was the best fit for me. It uses code generation to limit the boilerplate code that you may have to write, it is strongly typed so you can’t make as many mistakes, and it integrates into other codebases nicely.

Where should I use it?

It can be used in a normal api that single page applications interact with, but it can also be used in other situations like when you are working with microservices.

One of the use cases that I have been thinking about is when you have a service that contains lots of endpoints to retrieve small bits of data, and maybe you want an api to act as a facade over several other apis, gqlgen can be really helpful. Because of the way the resolvers (graphql lingo for data that returns data) work it can be really easy to plugin a grpc call to a remote service, or a capnproto call, or even call a rest api. This alone isn’t that much of advantage, but gqlgen also supports a pattern that facebook has coined “dataloaders”. Dataloaders are middleware that will block requests, and batch calls to dependent services. This means that several users can make a request for a resource, the data loader will typically wait for a certain duration (5ms for example), and then process the requests. This allows deduplication, but can also help to improve performance when lots of small but duplicate calls are performed.

Where should I not use it?

If you don’t need it, don’t use it. It’s just another piece of technology that needs to be updated, and maintained. Though if it brings you value, or if it allows your frontend developers to iterate faster on new features without asking backend developers to expose more data then it might just be the right tool for you.