Learn GraphQL - History and Reasons to Use GraphQL

#Introduction

Before you write a single line of schema, it's important to understand why GraphQL exists. Technology isn't born out of thin air; GraphQL was born out of a real problem Facebook faced while developing its mobile apps in the early 2010s.

Episode 1 dissects three things: the history and evolution of GraphQL, the REST API problems that drove its creation, and the advantages of GraphQL that led GitHub, Shopify, and Twitter to adopt it. We'll also compare GraphQL with REST and gRPC so you know when to use which.

You don't need to memorize the entire specification in this episode. What matters more is building intuition: what problem is being solved, and why does GraphQL's design answer that problem? This intuition will be your compass when you start writing schemas in episode 3.

Also, get into a problem-solving mindset. Every technology here was born out of a pain point — REST has too many endpoints, gRPC is too rigid for public clients — and understanding that pain is more valuable than memorizing syntax.

#The Evolution and History of GraphQL

#Born at Facebook in 2012

GraphQL was developed internally by the Facebook team in 2012, initiated by Lee Byron, Nick Schrock, and Dan Schafer. Their main motivation was the slow iOS app experience caused by fetching too much data from REST APIs. The news app had to load a list of stories, but each item needed comments, likes, and author metadata — which meant multiple HTTP round-trips for a single view.

In 2015, GraphQL was open-sourced along with its official specification. From then on the ecosystem grew rapidly: graphql-js became the reference implementation, and the community built tooling in many languages. In 2018, GraphQL was handed over to the GraphQL Foundation under the Linux Foundation, signaling that GraphQL had become a vendor-neutral open standard.

#Adoption by Large Companies

The adoption tipping point came when big companies publicized their successes: GitHub launched its GraphQL API v4, Shopify built GraphQL into all its e-commerce apps, and Twitter used GraphQL for its mobile apps. A recurring pattern: mobile teams need more precise data, and backend teams want to reduce the number of endpoints.

The timeline to remember: 2012 internal concept at Facebook, 2015 open-sourcing and spec release, 2018 entry into the GraphQL Foundation, and afterward ecosystems like Apollo, Relay, and modern tooling matured to where they are today.

One concrete proof that GraphQL is a vendor-neutral open standard is the existence of an official specification that anyone can implement. That's precisely why many companies feel safe investing in it: they're not tied to a single vendor or a single programming language.

If you're curious what it feels like to use a mature GraphQL API, try the GitHub GraphQL API, which is available through a single endpoint. Send a simple query with curl 'https://api.github.com/graphql' and observe the shape of the request and response before you build your own implementation.

#The Problems with REST APIs

#Over-Fetching and Under-Fetching

REST follows the principle of resources exposed through endpoints. The first problem is over-fetching: an endpoint returns the entire representation of a resource even though the client only needs part of it. A concrete example: the /users/1 endpoint returns 20 fields, while a profile screen only displays the name and avatar.

Conversely, under-fetching happens when a single view needs data from several resources. To render a news page, the client must call /posts, then call /posts/:id/comments for each post — that's the seed of the N+1 problem we'll cover in episode 9. Network load multiplies and mobile apps feel slow.

#Endpoint Proliferation and Versioning

The more use cases there are, the more endpoints appear: /users, /users/featured, /users/:id/posts, and so on. This is called endpoint proliferation. On top of that, API changes force versioning like /v1 and /v2, fragmenting clients and making evolution harder. On the documentation side, REST has no centralized contract, so docs easily fall out of sync with the implementation.

Imagine how many endpoints you'd have to maintain when every combination of data needs a new URL. Every feature addition means another endpoint, more documentation, and more logic to align response shapes. On the client side, every response change risks breaking an app already running in production.

This problem isn't just about code tidiness — it's also a team cost. Piling up endpoints slows down onboarding for new members, because there's no single place that summarizes the whole data contract.

#The Advantages of GraphQL

#Single Endpoint and Client-Specified Queries

GraphQL offers a single endpoint that accepts structured queries. The client decides exactly which fields it needs:

query BeritaTerbaru {
  posts(first: 10) {
    id
    title
    author {
      name
    }
    comments {
      totalCount
    }
  }
}

With the query above, the client gets the data it needs in a single round-trip. There's no over-fetching because only the requested fields are returned, and no under-fetching because relations can be combined into a single query.

#Strongly Typed Schema and Real-Time

Another advantage you'll appreciate in episode 3: a strongly typed and self-documenting schema. Because the entire shape of the data is defined in the schema, editors can offer autocomplete and validation before the request is even sent. Introspection lets tooling generate documentation automatically. Combined with subscriptions for real-time data (episode 16), GraphQL becomes a comprehensive solution for modern data needs.

#GraphQL vs REST vs gRPC

#Comparison Table

#When to Use Which

REST is still a good fit for simple public APIs, services dominated by CRUD operations, and ecosystems heavily dependent on HTTP caching. gRPC excels at high-performance inter-service communication, streaming, and use cases that need a binary protocol. GraphQL is the best fit when clients are diverse — web, mobile, and third-party — and need flexibility in fetching data, and when over-fetching starts becoming a real problem.

{
  "rest": "/users/1",
  "graphql": "query { user(id: 1) { name avatar } }",
  "grpc": "GetUserRequest { user_id: 1 }"
}

A common industry practice: use GraphQL as the API layer for clients, and let internal inter-service communication use REST or gRPC. This is the pattern we'll build in phases 4 and 8.

The final decision always depends on the team's context and product needs. Some teams start with REST and switch to GraphQL when the number of endpoints gets hard to manage; others go straight to GraphQL because they know from day one that their clients are diverse.

What matters isn't the technology label, but how fast the team can ship features without breaking along the way. The right technology is the one that best matches your team and product shape.

In the next phase you'll see this pattern in action: GraphQL in front for clients, REST or gRPC behind for inter-service communication. This big picture is what will shape the architecture we build throughout the series.

#Conclusion

Key takeaways:

• GraphQL was born at Facebook in 2012 to solve data problems in mobile apps, and was open-sourced in 2015.
• REST is prone to over-fetching, under-fetching, endpoint proliferation, and versioning complexity.
• GraphQL offers a single endpoint, client-specified queries, and a strongly typed, self-documenting schema.
• Subscriptions make GraphQL a good fit for real-time features.
• GraphQL, REST, and gRPC each have their own position; GraphQL excels as the API layer for diverse clients.

In the next episode, episode 2, you'll learn about the basic concepts and architecture of GraphQL — how requests are parsed, validated, and executed, the main components like SDL, the type system, and resolvers, and architectural patterns like gateways and federation. Prepare yourself to enter the most technical part of this series!