Ask Me Anything: GraphQL

Cole Turner
Cole Turner
6 min read
Cole Turner
Ask Me Anything: GraphQL

What questions would you like to ask a Software Engineer about GraphQL? I will try to answer your questions submitted through the form below.

Asked by Anya

Such a great question, because some folks wonder whether it's a choice between these options. In theory, a web application could use a SQL database, DocumentDB, and GraphQL!

Sounds wild right? Well it first helps to talk about the tradeoffs for these three technologies. Most people are familiar with SQL: it's a relational database where sets of data are stored in collections (often called tables). And most people know NoSQL databases like DocumentDB or MongoDB - and how they can provide flexibility and ease of use.

On the other hand, GraphQL can sit in front of SQL or DocumentDB (or both!). Think of GraphQL not as a database, but rather an entry point. Behind that entry point, the schema can point to records in a SQL database, or items in a DocumentDB. The beauty of GraphQL is that you can use anything you want, and your front-end clients won't know the difference. For example if our schema is an object of books and notes, we can resolve books with SQL and notes with DocumentDB. Or vice versa!

An analogy to help clarify is that GraphQL is kinda like a vending machine. You push a button, expecting to get what is defined by that button. Behind the door of that vending machine are several shelves, and it will fetch your choice. It knows where to look from any of the shelves that has your choice. I hope that helps!

Asked by Sebastian

This is always a fun question, because GraphQL is somewhat using REST under the hood. I assume this question means "does everything need to go through GraphQL?"

There are still times where REST makes a lot of sense. GraphQL solves a technical problem of having hundreds to thousands of data types. When something exists outside of that data type - it's doesn't necessarily need to be added into the GraphQL layer. Moreover, another advantage of GraphQL is that the schema can be augmented without as much risk to older clients. As long as the shape of schema is additive, and not re-shaped or deleted - older clients will continue to work. This can provide a safety net when you're working with a large array of client versions.

If the data types, schema, or client-driven development is not something that benefits developers working on your application - then REST will always be a valid option.

Asked by Alex

This is a good question because small teams and big teams do face different challenges. Here I am assuming at a small team is working on a small app, and a large team is working on something more enterprise.

Every team deals with adoption pains. GraphQL is not something you just migrate to — it's something you adopt. The same APIs you write in REST are not the same types or schema you create in GraphQL. Many teams struggle with this mind shift, and will create root-level fields that match what they did in their CRUD (create/read/update/delete) application. That's no better than a REST API. Embracing the graph structure in a schema is where the real value comes from, being able to connect from node to node.

Big teams deal with this on a larger scale. Usually there are some experts on hand to guide or curate the schema. In a big team, an assumption is made a feature developer can bootstrap a schema. However, a schema is larger than just one feature — it's a platform. Therefore, big teams and companies often deal with large schemas. And sometime that schema is spread out across services.

This has given rise to concepts like schema stitching or federation. There has historically been a lot of back and forth in the community where folks are divided between these two methodologies. This leads me to what I think is the biggest challenge: over-engineering. It's really easy to roll out the blueprints and plan for a large schema and spend a lot of time yak shaving, instead of just shipping.

Lastly there is the culture of adoption. While not everything needs to be in GraphQL, having buy-in across service dependencies can make a huge impact on the productivity and developer experience working in an app that interfaces with a GraphQL backend. Working in a divided codebase with a dozen frameworks and interface languages is taxing.

Asked by Anonymous.

I'm not sure how to answer this without knowing more about your application, but I can answer: it depends.

With any framework, it's easy to over-engineer your application. We don't want to adopt any technology or trend just because it has some buzz. It's important to understand what GraphQL provides: a single entry-point into your API, a strongly-typed schema for building scalable interfaces, and a domain language for querying and mutating data.

If you're building a blog or a simple website, then GraphQL is probably excessive for what you're trying to do. It's not going to provide much benefit over something like REST, and the added development time could instead get in the way of shipping.

On the other hand, if you're working with a large volume of interfaces or objects (users, articles, posts, products, etc) then the GraphQL schema can provide a lot of value. A GraphQL client could make managing this data much easier to scale, especially when building interfaces made up of components. And even for transactional websites, a GraphQL schema can provide a lot of value on creating stable, atomic APIs. These APIs are easier to debug, document, and annotate. When you're working with innovation and legacy clients, having a graph where that data can be guaranteed is useful.

So ultimately, what the choice comes down to is: does GraphQL add value to your development process? Would a schema help you manage data? Would a client save you the time and frustration of orchestrating data? Are you operating a service where someone else would want to consume that data?

It depends. 😀


Related Tags


More Stories

Why I Don't Like Take-Home Challenges

4 min read

If you want to work in tech, there's a chance you will encounter a take-home challenge at some point in your career. A take-home challenge is a project that you will build in your free time. In this post, I explain why I don't like take-home challenges.

Standing Out LOUDER in the Technical Interview

5 min read

If you want to stand out in the technical interview, you need to demonstrate not only your technical skills but also your communication and collaboration skills. You need to think LOUDER.

See more posts

Read it before anyone else. Subscribe to my newsletter for early access to the latest news in software engineering, web development, and more.