GraphQL
GraphQL
What is GraphQL?
- Request only the data you need, in one call
- Solves over-fetching and under-fetching
- An alternative to REST
Adding GraphQL shifts the decision about what data to return from the server to the client. With REST, every screen change meant the frontend asking the backend for a new endpoint and waiting for a deployment slot. With GraphQL, you just rewrite the query within the fields defined in the schema, and the screen changes that same day. No more waiting between teams is the first change people notice. In exchange, the responsibility for designing and versioning the schema becomes new work for the backend.
The endpoint is usually a single /graphql, and operations come in three kinds: Query (read), Mutation (write), and Subscription (real-time). The key difference from REST is caching. REST can use the CDN and browser cache per URL as is, but GraphQL sends POSTs to a single address, so it can barely use HTTP caching. You need to add a client cache such as Apollo or persisted queries. Errors also arrive inside an HTTP 200 response body, so monitoring that caught failures by status code has to be rebuilt from scratch.
The adoption test is surprisingly simple. GraphQL pays off when rendering a single screen takes 3–4 or more chained API calls and you have three or more clients, such as web, iOS, and Android. For a service focused on admin screens with only about 20 endpoints, REST is far cheaper to maintain. Rather than replacing REST outright, many Korean teams take a middle path: layer GraphQL on the BFF only to wrap the existing REST APIs.
The most common misconception is that it is always faster because it fetches everything at once. Inside the server, N+1 calls still happen, such as looking up the author separately for each of 20 posts, and without a DataLoader the DB connections run out first. Letting clients choose nesting depth freely is also risky: without depth and complexity limits, a single query can bring the server down. Authorization must be checked per field, not per URL, and teams that miss this have exposed salary or personal contact fields in real incidents.
Jaryong KooMarketing PhD and leading authority on AI, data analytics, and personal branding
Seungtae ParkAX practitioner who builds AI business development and marketing automation tools and teaches from that hands-on experienceA query language for APIs that Facebook developed internally in 2012 and released publicly in 2015. It standardized how clients request exactly the data they need.
Consider a hypothetical case. Company A is a fashion e-commerce company with 320 employees and KRW 180 billion (≈ US$134,670,100) in annual revenue. Loading a single product detail screen in its app took 7 REST API calls, stretching load time to 2.8 seconds on average. Every change in planning meant building new endpoints, so releases slipped by 2 weeks each time. The CTO assigned a 3-month improvement project.
- Kim, the mobile development team lead, pulled the access logs: a single product detail screen made 7 calls, average load time on LTE was 2.8 seconds, and the first-screen bounce rate was 18%.
- The backend lead objected: "If we build an endpoint for every screen, we will have over 200 addresses to manage." So the team kept the existing REST APIs and added a GraphQL gateway on the BFF layer.
- In the first 4 weeks, the team moved only three domains (products, reviews, inventory) to the schema. An N+1 problem surfaced when the review list looked up each author one by one, so they added a DataLoader and cut DB calls from 50 to 3.
- In the second week after launch, one partner sent a six-level nested query and pushed API server CPU to 92%. That night, the team enforced a query depth limit of 5, a complexity limit of 1,000, and persisted queries.
- Three months later, product detail calls dropped from 7 to 1 and average load time from 2.8 seconds to 1.1 seconds. Cases of waiting on a backend deployment for a screen change fell from 11 a month to 2.