Two weeks ago, I had an opportunity to immerse myself in everything GraphQL at GraphQL Europe in Berlin. While there, I asked some of the attendees why they had decided to come. Most answered that they’d heard of GraphQL and were there to learn more: that they wanted to see if it was right for their company, that they wanted to hear about other people’s experiences with it, and that they wanted to see if it was something they could adopt. The rest were already sold on GraphQL.

The mix of motivations made sense. Since Facebook open-sourced GraphQL in 2015, it has surged in popularity. Reasons for this include its strongly typed schema, which acts a contract between the client and server, offering clear visibility into all of an API’s supported operations, and GraphQL’s efficient approach to API endpoint interactions that provide engineers with far greater control over their query requests. Thus, three years after its unveiling at React.js Conf 2015, GraphQL has been adopted by developers working across the stack. And this was evident all around the conference. “It’s very different from last year,” people told me in a variety of ways. “Last year’s conference was all about trying out GraphQL. This year, it’s the stories of GraphQL in production.”

As my background at DigitalOcean is in the infrastructure world and Linux, I was a bit nervous to jump into a such a development-focused event. However, I found my fears ungrounded. While the talks opened up many questions, many themes and ideas resonated with me, and I left the event excited.

My goal in this post, therefore, is to share some of my personal takeaways as well as to encourage others, especially those who might feel nervous about diving more deeply into GraphQL, to take a closer look.

There are three themes in the conference talks that I found encouraging:

“Yeah, well, you know, that’s just, like, your opinion, man”

Straight out of the gate, GraphQL Europe opened a debate. Offering a study in contrasts, the first and third talk of the conference took opposite approaches to the question of whether a repo and GraphQL code should be in a monolith or broken up into microservices. In the monolith corner, Nick Schrok, the co-creator of GraphQL, presented his view of tech development, saying, “Those who learn too much from history are doomed to overreact to it.” As applied to microservices (especially in the context of GraphQL), the worst possible scenario, he said, ends up being a “distributed monolith”. He highlighted Facebook’s architecture as an example of an effective monolith (although it still uses services).

On the other hand, Johannes Schickling, the CEO of Prisma, argued that the added complexity of the monolith and the challenges in updating the code make breaking it up into services and layers a useful exercise — and that GraphQL facilitates doing this effectively. The takeaway for me from this contrast was not so much that one approach is better than another, but that GraphQL supports a variety of architectures. In highlighting two opposite approaches, with GraphQL at their heart, the question of what GraphQL’s relation is to the monolith (vs microservices) is opened for further discussion in the future. The choice of the most appropriate architecture at this point, therefore, is left as an exercise for the reader.

For example….

As with anything new, rallying a community around it involves teaching and sharing information effectively with others. To this end, there were two presentations during the conference focused on GraphQL education, each with a distinct approach. In his talk, “Teaching GraphQL,” Daniel Woelfel, the co-founder of One Graph, shared his 5 principles for presenting GraphQL:

1. Build concepts on top of each other
2. Teach new concepts with motivated narratives
3. Doing is understanding
4. Make your students independent
5. Entice their imagination with impressive demos

In a parallel approach, Jira Vinyoopongphan took on the real world challenge of “Making a Case for GraphQL: A recipe.” Among her ingredients and steps to cooking up company buy-in for GraphQL was the recommendation to highlight how GraphQL can address a pressing challenge being faced by a dev team.

While these two talks seemed to orbit the challenge of sharing GraphQL knowledge differently, I found the overlap in offering specific examples striking. Being able to see how a new idea you’ve learned has a real application is incredibly powerful, and these two talks highlighted that precisely. There is something here for beginners to GraphQL and for those seeking to teach it. Unsure beginners can ease their way into GraphQL by asking practitioners for specific usage examples, both to make it concrete for themselves and also to guide the potential educators on the best angle to present it. Those already well versed in GraphQL can find an entry point for presenting it to others by choosing some interesting use cases to start off with, if they aren’t sure about how to approach the overall ecosystem.

“Make it work!”

In listening to the event talks, I was reminded that, although GraphQL’s capabilities are efficient and exciting, the technology is still young, growing in a mostly REST world. Nevertheless, the conference presentations actually demonstrated how this environment underscores GraphQL’s flexibility. They covered the real world situations that GraphQL users may find themselves in and touched on how they might play out for various companies. The overall pattern that emerged was that GraphQL has a high degree of adaptability in different existing tech architectures. There seemed to be a couple of possible states for GraphQL within a stack:

• GraphQL native: GraphQL implemented and used in production exclusively, without REST
• Migration from REST to GraphQL: A company going all in on GraphQL, with a goal of making the migration from REST as seamless as possible
• GraphQL over REST: With REST entrenched in a codebase, such a setup is geared toward getting access to the most useful features of GraphQL without the heavy lift of a full scale migration

As a bonus, Nicholas Van Wiggeren (in “Fast, Slow, Beautiful, Ugly: Building GitHub’s Platform”) shared an interesting and very uncommon use case for GraphQL at Github, where REST was used over a GraphQL implementation. While this was unique to Github’s setup, it fit the pattern of the other talks: that engineers can make inroads with GraphQL with a broad array of approaches.

“That’s all, folks…”

My highlights are only the tip of the iceberg. In sharing them, I hope to illustrate that just as GraphQL can make a home within a company’s stack in a variety of ways, so too, can individuals find many approaches to playing around with it. With its usage still evolving, as beginners, we can see that there isn’t, yet, one right answer for how it can be used, that teaching GraphQL is a two-way street (that is, we should ask about what we want to learn, and teachers can use examples to help us understand), and that because every codebase is different, the role that GraphQL has in it can vary.

As a young open source project, GraphQL is learning from its community. The failures and successes you experience with it can feed straight back into its growth, whether to help people teach it better, to find interesting new ways to implement it, or to spark conversation (can we say debate?) about it overall. Dive in!

Bonus

There are a lot of great resources to get started with GraphQL. Here are some to check out: