On helping shape the GraphQL Community

If you've written a GraphQL query in the last few years, in or out of DatoCMS, there's a solid chance you've used a tool that Julian Bauer and the fine folks over at Overnice helped design.

You might not know it, but the GraphQL Explorer you use in DatoCMS, or any other GraphQL CMS, or countless other GraphQL-powered tools, has roots in the work he did with his team years ago.

Today, he's still heading up Overnice, one of our friends in the DatoCMS partner ecosystem, building, in his words, "unnecessarily nice brands and products".

Overnice is a Berlin-based brand and product studio with a knack for turning complex, sometimes dry products into something that feels intuitive and joyful. “We like the challenge of taking something complicated, maybe even boring, and making it approachable and accessible,” Julian says. “Why should good UX be reserved for lifestyle brands?”

Touché.

Anyways, we're not here to talk about their projects today. Heck, we're not even here to talk about their work with us. We're looking to dive into the GraphQL explorer and revive some old memories from the early days ☕️

The birth of the GraphQL Playground

The story for Overnice and Julian started back in 2017, when Prisma was still called Graphcool. “They were building a backend as a service based on GraphQL. The .cool TLD had just come out, so Graphcool made sense,” Julian laughs. “They needed a GraphQL Explorer. GraphiQL existed, but it was missing features and, honestly, it was ugly.”

If you're new to the space or don't remember the OG GraphiQL, here's what it looked like 👇

Working with Prisma, they helped design the GraphQL Playground, a more polished, user-friendly alternative to GraphiQL.

It was open sourced and quickly gained fans. “GraphiQL was still the standard, but Playground attracted devs who cared about the DX,” Julian remembers.

Side note: They also collaborated on How to GraphQL, the interactive tutorial on GraphQL from Prisma that’s still popular today!

Since then, Prisma moved away from GraphQL to become the TypeScript ORM to now a serverless Postgres DB, but all the work they put into the GraphQL space has helped shape what it is today.

Today's GraphQL Explorer

Fast forward to 2022. The GraphQL community wanted a single standard tool. The idea was to merge the best of GraphiQL and Playground. Overnice, as the team behind the original Playground, was brought back to handle the redesign along with the fine folks at Stellate (then GraphCDN), who had worked with Julian back when they were at Prisma.

So many early GraphQL days memories brewing...

Anyways.

The "redesign" of the Playground was focused on making a genuinely gorgeous tool that focused on the DX and provided a really smooth and intuitive experience. Docs, actions, env switchers, everything should be in the right place where they belong.

Julian remembers a small but important change: the play button.

In the original GraphiQL, the play button was way up in the top left. You typed in the editor, moved your eyes left, then back right to see the result. It was this weird zig-zag flow. We put the play button in the middle, between the panes. It felt odd at first but now it’s natural.

Another focus was making the docs explorer feel more connected to the editor.

Before, it was like two separate products in one. You’d look up your schema in the docs, then manually type it into the editor. We wanted you to click fields directly in the docs to build your query. So we moved the docs to the left, made them the starting point, and added a tree structure to click together a query.

This “click-to-query” model was inspired partly by other tools but made its way into the modern Explorer, and it’s now the default for many dev-focused products.

From Designers to Users

Of course, if you've been working in the space (especially building websites) long enough, you'll see yourself go from tool creator to tool users, and things were no different for Julian and the Explorer, especially given how deeply ingrained into Headless CMS tools it's become.

It literally happened when I opened DatoCMS one day and thought, wait a minute… isn’t that the GraphiQL we designed? It made sense that you guys would use it, but it was still a cool moment.

For Overnice, the Explorer isn’t just a past project. It’s a core part of their workflow today. Even in recent projects where they were tasked with building a multi-domain, multilingual site with a complex role and permissions setup, the Explorer was crucial in testing out all their queries before moving it to the repo.

“Before we wrote a single line of front-end code, I used the Explorer to prototype the schema. Could an admin see everything? Could a local maintainer see only their events? Would the multilingual structure query cleanly? It let us test all of that before building anything.”

That schema-first approach saved them hours, if not days, of development time.

A real I-should-pat-myself-on-the-back-for-this moment.

Dev workflow candy

One thing Julian is particularly proud of is how adaptable the Explorer turned out to be.

“It can be ultra complex with tabs, variables, docs, and multiple panes. Or it can be stripped down to just an editor and results window inside a docs page. But it doesn’t feel like a generic boilerplate in either case.”

That adaptability matters when a single tool ends up in tons of products, each with its own brand and UX quirks.

We wanted it to feel like it belonged wherever it was embedded, but still feel designed. That’s a fine line.

And it's true. In DatoCMS it really looks like a "core native" part of the product, as is the case with many other CMS tools that embed the explorer.

Julian's more of the design guy, so he really wanted a more up-to-date account of how devs feel about the Explorer in the context of today's GraphQL landscape. So we had a chat with his teammate Jonny, who works most with GraphQL day to day, to ask how it fits into his workflow.

The magic combo for him? Fragments + type generation with gql.tada paired with the Explorer for testing things out👇

“He keeps the part of the query that’s relevant to a component right next to the component itself. Update the block, update the query. With gql.tada, you get types from that instantly, with autocomplete and type safety. And if something’s off, you debug in the Explorer. It just feels like the way it should be.”

That tight loop? Write your query, see your types, test in the Explorer? That's become a core part of so many dev process when working with GraphQL, it's honestly crazy to think about just how widespread this has become.

When asked if he expected the Explorer to become as widely adopted as it is, Julian pauses. “Not really. Back when we did Playground, GraphiQL was still the big one. I think it only sank in when we were redesigning GraphiQL itself. Suddenly I saw the GitHub stars and realised… this is everywhere.”

For devs, the Explorer is just another tool in the stack. But for Julian, it’s a reminder that small UX decisions, like moving a button a few centimetres for example, can change the expected DX across an entire ecosystem.