강의

멘토링

로드맵

GraphQL for Document-Based Framework Communication Patterns, as Explained by a Kakao Interviewer

When you find yourself constantly modifying Swagger documents, aligning API specs, and communicating back and forth with the frontend, you start to wonder, "Why am I doing the same thing twice?" I felt that same frustration in the field, which led me to dive deep into GraphQL and develop an interest in data-driven design. This course isn't just about simple GraphQL syntax; it covers why it emerged to solve real-world service problems, along with practical considerations like Resolver structures, the N+1 problem, and Federation. I have designed this course to help you naturally learn how to reduce communication costs between developers and design a more flexible API structure.

33 learners are taking this course

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

  • You will gain a sense of how to design GraphQL schemas for actual services, rather than just writing simple queries. You will come to understand "why the structure is divided this way."

  • By directly solving the recurring Over Fetching and Under Fetching issues found in REST APIs, you will experience how frontend and backend teams can collaborate more flexibly around data.

  • By directly addressing performance issues encountered in practice—from structuring Resolvers to DataLoaders and N+1 problem-solving strategies—you will be able to build "operable GraphQL" rather than just "working GraphQL."

  • Instead of the spec inconsistency issues that arose from managing Swagger documents separately, you will understand the introspection-based self-documenting structure and gain a new perspective on API documentation methods themselves.

  • Beyond simple CRUD levels, you will learn advanced patterns such as Federation, Subscriptions, and authentication handling, allowing you to understand the flow of how to scale GraphQL in actual large-scale service environments.

Document-based communication?? Swagger?? What is all of this??

  • The content below is an actual conversation.

😄 Hong : It's so annoying at work because they demand Swagger even for just one API development... It's such a hassle having to match the format and update it every time the specs change.

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

😄 Hong : It's frustrating, can't we just look at the .proto file like gRPC and develop with a DDD feel?

😁Kakao Interviewer (Developer) : You've grown, you ordinary man... lol. Just kidding, but I think what you're saying isn't necessarily wrong.

😁Kakao Interviewer (Developer) : In the past, I also just did things the same way because everyone else was doing it, but even while doing it, I had questions like, "Why am I doing it this way??" I think I ended up growing because I pursued different approaches while having those thoughts.

😁 Toss Developer : Hahaha Hong, you amateur... Hahaha that's why GraphQL exists. Was it made by Facebook?

😁Kakao Interviewer (Developer) : Yeah, so as I was studying, I ended up using it quite a bit. Just like Hong said, it's the same as gRPC. In fact, it feels like conducting HTTP communication in a standardized way.

😁Kakao Interviewer (Developer) : I'll tell you about this lol. Since we're talking about it, as a GraphQL veteran, I feel like diving into it for the first time in a while.

How can we handle spec documentation, which developers often avoid, to reduce communication costs when collaborating with one another? ⚡

In an environment where numerous services are connected around data, we move beyond simple REST API design to contemplate “how to deliver and consume data” itself.

While the backend provides pre-prepared data, the frontend often receives unnecessary fields, or conversely, finds itself repeatedly calling multiple APIs just to construct a single screen.

As a result, these concerns naturally begin to 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 to go??

  3. Why do issues where the Swagger specification document and the actual response structure don't match keep recurring??

  4. Is there a way for the frontend and backend to collaborate more flexibly around data??

GraphQL starts from exactly this kind of problem awareness.

It is not simply a technology to replace 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 actual industry settings and
in what situations it is more powerful than REST. We will also look at structural issues inevitably encountered in practice—going beyond simple CRUD—such as Schema design, Resolver structuring, solving the N+1 problem, utilizing DataLoader, Federation, Subscription, and authentication handling.

Through this course, I will help you grow not just as a "developer who knows GraphQL syntax," but as a "developer who can design data-centric API structures." 🚀

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

GraphQL is not just a simple API technology. ⚡

In a traditional REST-based architecture, as the data requirements for each screen vary, the number of APIs increases accordingly.
When Web, Mobile, and Admin pages start requiring different sets of 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 is needed," and the server combines and returns only the requested data accordingly. In other words, instead of the server designing APIs based on the screen, it operates centered around the data structure itself.


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

You can organically connect different data sources, such as User Databases, Post Databases, external APIs, and Comment systems, under a single Schema. This allows the frontend to fetch 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 will cover everything from what role a real Resolver plays,
why a DataLoader is necessary,
why the N+1 problem occurs,
to how the Schema should evolve as the service scale grows.


You will not only learn "how to use GraphQL," but also the mindset of how to design and connect data in a complex service environment. 🚀

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 an actual service environment, you will encounter more diverse problems than you might expect.

  1. The call structure becomes more complex as the number of Resolvers increases,

  2. The N+1 problem caused by a single Query written without careful thought

  3. Schemas that become excessively bloated,

  4. Permission handling and caching strategies,

  5. Even Federation design in an MSA environment

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

A sneak peek at the actual course content 🍡

Data migration and GUI using Prisma

DataLoader pattern to prevent the N+1 problem, the most critical issue in 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 12-year backend server developer who works on server development at Kakao and also serves as an interviewer.

I first connected with Hong at a Conference in the past, and since the middle of my lecturing career, we have continued to actively participate together, creating courses on various topics. I believe that talking and communicating with many people while creating these courses has been very helpful in my life as a developer and has allowed me to learn from diverse perspectives, so I am striving to cover an even wider range of topics.

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

[Current] Kakao Headquarters Server Developer

[Former] Majored in Computer Science 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 repeat the process of modifying Swagger and aligning API documentation.

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

  • Developers who have looked at GraphQL syntax but still don't have a feel for actual resolver structures or practical design methods.

  • Server developers who are contemplating how to connect and manage data flow in MSA environments or large-scale service architectures

  • A developer who wants to grow by understanding "Why did this technology emerge and what problem is it trying to solve?" rather than just learning how to use it.

Need to know before starting?

  • This is a course for beginners! Since the difficulty level is low, no prior knowledge is required.

Hello
This is Hong

Inflearn Verified

Career Verified

9,462

Learners

585

Reviews

157

Answers

4.7

Rating

32

Courses

Introduction

I started studying development after finding an interest in it while idling at home, and I am currently in charge of 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 various problems and solutions you may encounter in practice.

 

These lectures are not created solely through my own knowledge. Every lecture is made possible by the people who work together with me.

 

Knowledge Sharer Career

[Former] Sandbox IP-related blockchain developer

[Former] Metaverse Backend Developer

[Current] A seasoned server developer based in Pangyo

 

Interview History

Other Inquiries

  • unduck2022@gmail.com

Curriculum

All

16 lectures ∙ (3hr 58min)

Course Materials:

Lecture resources
Published: 
Last updated: 

Reviews

Not enough reviews.
Please write a valuable review that helps everyone!

Limited time deal

$655,554.00

59%

$59.40

Hong's other courses

Check out other courses by the instructor!

Similar courses

Explore other courses in the same field!