It’s difficult to be a developer and not experience the hype around GraphQL. I’ve spent the last three years implementing GraphQL APIs in Elixir and Node, watching the tooling and community grow along the way. In this post, I want to shed some light on the pros and cons, breakdown some of the packages used and leave you and your team with enough insight to make an informed decision on GraphQL.
If you would like to skip the history and packages and read the pro and con section scroll down to GraphQL the good and bad. Sadly, I could not get anchor tags to work today in Medium. ¯\_(ツ)_/¯
GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.
As is with any new shiny web tool we’ll start with the docs.
The documentation found at graphql.org does a good job at defining what GraphQL is and isn’t, so I’m not going to veer too far from that here. Navigating to graphql.org you’ll arrive at a landing page that gives a quick three bullet response to the most common pros.
We will talk about these points more in a moment, but for a lot of lead developers, we have the responsibility to research these tools to ensure their merit. The last thing you want is to see your team ramp up on a new open-sourced tool only to have it crumble from underneath us a few months later. With the open-sourced community being well, open-sourced, it is easy to have a pessimistic approach to development and the tools we use, or at least I do. My internal conversations start with something like, “That all sounds great, but everyone hypes up their work. How do I know I can trust this one?”
Let’s take a quick dive into how it all started and where a few packages are now.
History of GraphQL tools
Great! GraphQL seems legit enough to look into further, but now I notice there’s a ton of tooling and ways to implement it.
Agreeably, the noise is hard to sort through. You search GraphQL and a ton of articles (like this one), packages, and tools all appear. There are even articles like this one “13 GraphQL Tools and Libraries You Should Know in 2019” that try to set expectations for what developers should know.
I’m going to highlight a few of them as a quick overview of where we are:
NOTE: I’d like to mention that ALL of these packages have merit. There is no one-size-fits-all GraphQL package. I suggest you explore the community, look around and find what best suits your needs. This is not meant to weigh one over the other but hopefully can help get you started.
As the community took off with GraphQL, you could imagine it became sort of a leg race to be THE GraphQL solve all. If you ask me — that marathon is continuing today. The remaining list below has grown and evolved since their first iterations. As a brief of each, I may have left something out, but again they each have merit, so if something strikes your interest, dive in!
One of the first tools I remember seeing on the scene — GraphQL Yoga. A look into GraphQL Yoga and you’ll see that it is a collection of packages and tools brought together to make remembering all the boilerplate setup you may need easier. When it started, it used the express-graphql package above, but you’ll notice now that it uses one of the other tools mentioned here: Apollo Server. So, why not just use Apollo Server instead? Some may opt for just that. GraphQL Yoga becomes an abstraction with pros and cons. How much code do you wish to maintain vs having a tool do it for you? Will you run into a wall at some point? In my experience, using any magical create-thing-package will at some point lead to issues. However, for most common apps, you may be just fine. Use your judgment.
GraphQL Yoga’s Pitch:
Using these packages individually incurs overhead in the setup process and requires you to write a lot of boilerplate. graphql-yoga abstracts away the initial complexity and required boilerplate and lets you get started quickly with a set of sensible defaults for your server configuration.
graphql-yoga is like create-react-app for building GraphQL servers.
Prisma is now working on 2.0 which is to include its own type of ORM tooling expanding the above into a more chain-able dot syntax and expanding it’s database migration tools.
At this point, GraphQL as a service seems to be a big push. I’ll be interested to see how some of these tools shake out over time. Prisma learned a lot through its first iteration, and while the initial 1.0 setup felt a bit off, 2.0 seems to be making leaps based off community feedback. This is worth keeping an eye on.
Do you run all your services in the cloud already? Are you considering it? Do you want to jump on the Serverless train? AWS, like other tooling, brings their services together to provide what seems to be as close to GraphQL as a service as you can be. I believe as these tools continue to mature, we will see more of a “point this tool at your database…” type of setup. You can set up your DB of choice, add your Schema, Resolver logic, and let AWS manage the rest. Using AWS, which has its own learning curve, removes a lot of the overhead and boilerplate. You’ll be up and running quickly and back to focusing on solving your project’s problems, instead of configuring all the things. This also gives you the freedom to quickly tie into other AWS resources such as S3. Do you need to have an endpoint to upload files? Chances are you were probably going to use S3 anyway. Do you have IAM roles set? Use them with GraphQL for your authorization and between Amplify and AppSync you’ll be set in no time.
Do you want to stay up to date with AWS Amplify? I’d recommend giving Nader Dabit a follow.
I know I said there was no one-size-fits-all GraphQL package, I kind of lied. It’s hard to search GraphQL and NOT see Apollo mentioned at this point in the game and for a good reason. While AWS and others are pushing forward with serverless tech, Apollo, at least for now, has kind of set the standard for server/client setups. Regardless of which server-side setup you choose, you’ll be reaching for Apollo at some point for the client-side. Apollo client has been the most supported, and community-driven. It has also improved upon its cache store, subscriptions, and stayed up to date with ESX features and state management features like React Hooks. At this point, Apollo has enough tooling and configuration options to merit its own blog post. It’s safe to say if you aren’t sure which option is best for your team, Apollo is a safe bet.
While this may be obvious, it’s worth noting. GraphQL has the support of a rallying community. Don’t recreate the wheel before checking out the open-sourced world for solutions. You’ll spend a lot of time building out GraphQL boilerplate that could have been a simple import. Below are some packages that come to mind:
I usually go by a quick smoke test to determine if GraphQL is worth it.
As to what tools, packages, etc., that is up to you. Use GraphQL for what you need, how you need it, with the tools you need.
This should serve as a good primer for choosing or not choosing GraphQL on your projects. I plan to follow up on this overview with some code. “GraphQL — Talk is cheap, show me the Code!”
I’ll be diving into some of the patterns mentioned here, and showcasing some of our own “gotchas” we’ve solved for along the way. Stay tuned!
Matt Thompson is a lead engineer at Echobind, mentor, and content creator. Matt spends most of his time finding ways to improve the process for others. When he’s not building software, you’ll find him enjoying time with family, unplugging with a book, and woodworking.