A Quick Intro to GraphQL (And Why It’s Taking Over)

If you’ve built a website before, you know the drill. You need to display a user’s profile, so you write a fetch request to some API endpoint like /api/users/67.

The server responds, and usually, it dumps everything on you. You get the user’s name, email, address, hair color, favorite food, and a timestamp of when they created their account.

But all you really wanted was their username.

Now you’re downloading a bunch of data you don’t need (which slows down your app), just to use one field. Or, even worse, you need their username and their last three posts. The user endpoint doesn't have the posts, so now you have to make a second fetch request to /api/posts.

This is the problem GraphQL was built to solve.

It’s basically just a smarter way to ask for data

With standard APIs (REST), the server decides what you get. With GraphQL, you decide what you get.

It’s a query language. That sounds intimidating, but it’s actually really intuitive. Instead of hitting a specific URL for specific data, you hit one single URL and send a "query" that looks almost like JSON.

If you want a user’s name and their posts, you just write something like this:

query { user(id: "67") { username posts { title } } }

And the server sends back exactly that. No extra junk, no missing fields. Just the data you asked for, in the exact shape you asked for it.

Why it’s nicer to work with

No more chaining requests: You don’t have to fetch the user, wait for the response, get the ID, and then fetch their posts. You can grab nested data (User -> Friends -> Friends' Posts) in one single go.

You know what you’re getting: Since the queries are specific, you don't have to print out the response just to see what the data looks like. The code literally just tells you exactly what fields are coming back.

The catch

It’s not perfect. Setting up a GraphQL server can be a little more work than a standard one, especially for simple projects. In addition, it’s also not supported by a lot of different APIs right now, as it’s fairly new and not very widespread just yet.

But on the frontend (React, Vue, mobile apps), it’s a dream. It stops you from fighting with the API and lets you just focus on building your UI. If you’re tired of managing a dozen different API endpoints, you should give it a try.