GraphQL for Document-Based Framework Communication Patterns: Insights from a Kakao Interviewer

When you find yourself constantly updating Swagger documentation, aligning API specs, and repeatedly communicating with the frontend, you start to wonder, "Why am I doing the same thing twice?" I also felt similar frustrations in my professional experience, which led me to use GraphQL extensively and develop an interest in data-centric design. This course goes beyond simple GraphQL syntax; it explores the real-world problems it was created to solve, along with practical considerations like Resolver structures, the N+1 problem, and Federation. I've structured this course to help you naturally learn how to reduce communication costs between developers and design more flexible API structures.

(5.0) 2 reviews

85 learners

Level Beginner

Course period Unlimited

TypeScript
TypeScript
JavaScript
JavaScript
GraphQL
GraphQL
MSA
MSA
Government-Funded Bootcamp
Government-Funded Bootcamp
TypeScript
TypeScript
JavaScript
JavaScript
GraphQL
GraphQL
MSA
MSA
Government-Funded Bootcamp
Government-Funded Bootcamp

What you will gain after the course

  • Beyond simply writing queries, you will gain a sense of how to design GraphQL schemas for real-world services. You will come to understand "why the structure is divided this way."

  • By directly solving the recurring over-fetching and under-fetching issues in REST APIs, you will experience how frontend and backend can collaborate more flexibly around data.

  • By directly addressing performance issues you'll inevitably encounter in practice—from resolver structuring and DataLoader to N+1 problem-solving strategies—you'll be able to build "production-ready GraphQL" rather than just "GraphQL that works."

  • Instead of the spec mismatch issues that arose from managing Swagger documentation separately, you will understand introspection-based self-documenting structures and gain a new perspective on the API documentation process itself.

  • Beyond simple CRUD, you will learn advanced patterns such as Federation, Subscription, and authentication handling, enabling you to understand how to scale GraphQL in real-world, large-scale service environments.

Documentation-based communication?? Swagger?? What is all this??

  • The content below is an actual conversation.

😄 Hong : At work, it's so annoying even when just developing a single API because they demand Swagger so much... It's such a hassle having to match the format and update it every time the spec changes.

😄 Hong : I feel this every time... we have to do Swagger and write documentation, so why are we doing the same work twice? If it's just limited to communication between developers, I personally don't see why documentation is so important.

😄 Hong : It's frustrating, can't we just develop with a DDD approach by looking at .proto files like gRPC?

😁Kakao Interviewer (Developer) : You've grown, mere mortal... lol Just kidding, but I think you're not entirely wrong either.

😁Kakao Interviewer (Developer) : In the past, I also just did the same thing because everyone else was doing it, but even then, I had questions like "Why are we doing it this way??" I think I grew as I pursued other things.

😁 Toss Developer : Hahaha Hong, you mere mortal... Hahaha that's why GraphQL exists. Didn't Facebook make it?

😁Kakao Interviewer (Developer) : Yeah, so as I was studying, I ended up using it quite a bit. It’s just like gRPC, as Hong mentioned. It basically feels like standardizing HTTP communication.

😁Kakao Interviewer (Developer) : I'll tell you about this lol. Since we're on the subject, I've wanted to dive into GraphQL again as a veteran after a long time.

How can we reduce communication costs among developers when it comes to spec documentation, which is something developers often avoid? ⚡

In an environment where numerous services are interconnected around data, we move beyond simple REST API design to contemplate “how data should be delivered and consumed” itself.

While the backend provides pre-prepared data, the frontend often receives unnecessary fields, and conversely, situations where multiple APIs must be called to construct a single screen keep repeating.

As a result, these concerns naturally arise.

  1. Why can't we just request only the data we need??

  2. Is a structure where API versions keep increasing really the right way??

  3. Why does the problem of the Swagger specification and the actual response structure being out of sync keep recurring??

  4. Isn't there a way for frontend and backend to collaborate more flexibly around data??

GraphQL starts from exactly these concerns.

It is not just a technology that replaces REST, but an approach that redesigns the role of the API itself by allowing clients to directly define and fetch the data they need. I will explain why GraphQL emerged in the real world and
in what situations it is more powerful than REST, while also exploring structural issues that are inevitably encountered in practice—such as Schema design, Resolver structuring, N+1 problem solving, DataLoader utilization, Federation, Subscription, and authentication handling—going beyond simple CRUD levels.

I will help you through this course so that it becomes a process of growing into a "developer who can design data-centric API structures” rather than a “developer who knows GraphQL syntax.” 🚀

TypeScript, JavaScript, GraphQL, MSA, Government-funded bootcamp

GraphQL is not just a simple API technology. ⚡

In traditional REST-based architectures, the number of APIs increases as the data required for each screen varies.
When Web, Mobile, and Admin pages start requiring different data, the backend ends up continuously adding similar APIs, making the structure increasingly complex.


However, GraphQL takes a slightly different approach.

The client directly defines "what data it needs," and the server combines and returns only the necessary data in response to that request. In other words, instead of the server designing APIs based on the screen, it operates with a focus on the data structure itself.


Furthermore, GraphQL does not simply look at a single database.

Different data sources such as User Databases, Post Databases, external APIs, and Comment systems can be organically connected under a single schema. This allows the frontend to fetch the necessary data through a single endpoint without needing to know the internal structure.


As I mentioned, this course does not simply explain Query syntax.

We cover what role the actual Resolver plays,
why DataLoader is necessary,
why the N+1 problem occurs,
and even how to evolve the Schema as the service scales up.


You will not just learn "how to use GraphQL," but you will also acquire the mindset of how to design and connect data in complex service environments. 🚀

However, GraphQL is not a silver bullet. ⚡

Many developers initially approach GraphQL simply as an “API technology that is more convenient than REST.”

However, in actual production environments, you will encounter more diverse problems than you might expect.

  1. Call structures that become more complex as the number of resolvers increases,

  2. The N+1 problem caused by a single query written without much thought

  3. Schemas that become excessively bloated,

  4. Authorization handling and caching strategies,

  5. Up to Federation design in an MSA environment

In the end, what matters is not "GraphQL syntax," but the perspective on how to design data flow. 🚀

A sneak peek of the actual lecture content 🍡

Data migration and GUI using Prisma

DataLoader pattern to prevent the N+1 problem, the most critical issue of databases

Subscription pattern for asynchronous and event communication (PubSub)

The career background of the Kakao interviewer who helped prepare this lecture 🤭

I am Choi, a backend server developer with 12 years of experience who works on server development and serves as an interviewer at Kakao.

I first connected with Hong at a Conference in the past, and since the middle of my lecturing career, we have continued to actively collaborate to create lectures on various topics. I believe that communicating and interacting with many different people through the process of creating these lectures has been a great help in my life as a developer and a time to learn from diverse perspectives, so I am working hard to cover an even wider range of topics.

While I don't believe that a background at a so-called "big tech" company alone proves that someone is a great developer, I do believe it offers exposure to significantly higher traffic and broader experiences compared to typical platforms. I will strive to incorporate these insights into my lectures to share them with you.

[Current] Server Developer at Kakao HQ

[Former] Computer Science major at a 4-year university in Seoul

Practice Environment

  • OS :

    Apple M3 Air

  • Node : v25.5.0

  • IDE : VsCode

Recommended for
these people

Who is this course right for?

  • A backend developer who thinks "Why am I doing the same thing twice?" every time they have to update Swagger and align it with the API documentation.

  • A developer exhausted from calling multiple REST APIs to build a single screen while constantly coordinating data specifications with the frontend.

  • Developers who have explored GraphQL syntax but still haven't quite grasped actual resolver structures or real-world design patterns.

  • A server developer contemplating how to connect and manage data flows in MSA environments or large-scale service architectures.

  • A developer who wants to grow by understanding "why this technology emerged and what problem it aims to solve," rather than just how to use it.

Need to know before starting?

  • This is a course for beginners! No prior knowledge is required as the difficulty level is low.

Hello
This is Hong

Inflearn Verified

Career Verified

10,000

Learners

630

Reviews

165

Answers

4.7

Rating

32

Courses

I started studying development after becoming interested in it while idling at home, and I am currently responsible for platform server development in Pangyo. I am continuing my activities as a knowledge sharer because I want to provide you with the methods I used to study, as well as the various problems and solutions you may encounter in practice.

 

These lectures are not created solely through my own knowledge. There are others who collaborate on every lecture.

 

[Instructor Career]

[Former] Blockchain developer related to Sandbox IP

[Former] Metaverse Backend Developer

[Current] A server developer becoming a veteran in Pangyo

 

[Interview History]

[Other Inquiries]

[Official Site]

More

Curriculum

All

16 lectures ∙ (3hr 58min)

Course Materials:

Lecture resources
Published: 
Last updated: 

Reviews

All

2 reviews

5.0

2 reviews

  • warna97725274님의 프로필 이미지
    warna97725274

    Reviews 13

    Average Rating 5.0

    5

    81% enrolled

    I think it's great for listening lightly as an introductory course. Thank you!

    • jukascrow6433님의 프로필 이미지
      jukascrow6433

      Reviews 9

      Average Rating 5.0

      5

      88% enrolled

      If you are curious about GraphQL, I highly recommend this as an introduction. I also knew nothing about it, but after taking this course, I got a good feel for it and am now in the process of applying it to my actual work. Thank you.

      Hong's other courses

      Check out other courses by the instructor!

      Similar courses

      Explore other courses in the same field!