강의

멘토링

로드맵

GraphQL cho mô hình giao tiếp framework dựa trên tài liệu qua chia sẻ của người phỏng vấn Kakao

Khi sửa đổi tài liệu Swagger, điều chỉnh đặc tả API và liên tục giao tiếp với phía Frontend, bạn sẽ nảy sinh suy nghĩ: "Tại sao mình cứ phải làm đi làm lại cùng một việc thế này?". Bản thân tôi cũng đã cảm thấy rất bế tắc tương tự trong thực tế công việc, và trong quá trình đó, tôi đã sử dụng sâu GraphQL và bắt đầu quan tâm đến phương pháp thiết kế lấy dữ liệu làm trung tâm. Khóa học này không chỉ đơn thuần dạy về cú pháp GraphQL, mà còn đề cập đến những vấn đề thực tế như: GraphQL ra đời để giải quyết vấn đề gì trong các dịch vụ thực tế, cấu trúc Resolver, vấn đề N+1, và Federation. Tôi đã xây dựng nội dung sao cho bạn có thể tiếp thu một cách tự nhiên luồng thiết kế cấu trúc API linh hoạt hơn, đồng thời giảm thiểu chi phí giao tiếp giữa các nhà phát triển.

33 học viên đang tham gia khóa học này

Độ khó Nhập môn

Thời gian Không giới hạn

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

Bạn sẽ nhận được điều này sau khi học.

  • Không chỉ dừng lại ở mức độ viết Query đơn thuần, bạn sẽ có được cảm nhận về cách thiết kế GraphQL Schema trong các dịch vụ thực tế. Bạn sẽ hiểu được lý do "tại sao lại chia cấu trúc như thế này?".

  • Bằng cách trực tiếp giải quyết vấn đề Over Fetching / Under Fetching vốn thường lặp lại trong REST API, bạn sẽ được trải nghiệm cách frontend và backend có thể hợp tác linh hoạt hơn xoay quanh dữ liệu.

  • Bằng cách trực tiếp xử lý các vấn đề hiệu suất chắc chắn sẽ gặp phải trong thực tế, từ cấu trúc Resolver, DataLoader cho đến chiến lược giải quyết vấn đề N+1, bạn sẽ có thể tạo ra một "GraphQL có khả năng vận hành" thay vì chỉ là "GraphQL chạy được".

  • Thay vì vấn đề không nhất quán về đặc tả phát sinh khi quản lý tài liệu Swagger riêng biệt, chúng ta sẽ hiểu về cấu trúc tự tạo tài liệu dựa trên Introspection và có một cái nhìn mới về chính phương thức lập tài liệu API.

  • Vượt qua cấp độ CRUD đơn thuần, bạn sẽ được học các mô hình nâng cao như Federation, Subscription, xử lý xác thực, từ đó hiểu được luồng cách mở rộng GraphQL trong môi trường dịch vụ quy mô lớn thực tế.

Giao tiếp dựa trên tài liệu?? Swagger?? Những thứ này là gì vậy??

  • Nội dung dưới đây là nội dung cuộc trò chuyện thực tế.

😄 Hong : Ở công ty, thực sự ngay cả khi chỉ phát triển một API thôi cũng thấy rất phiền phức vì họ yêu cầu Swagger quá nhiều... Phải làm cho đúng định dạng đó rồi mỗi khi thông số thay đổi lại phải sửa đổi cùng lúc nên mệt mỏi lắm

😄 Hong : Lúc nào tôi cũng cảm thấy vậy.. vừa phải làm Swagger, vừa phải viết tài liệu, tại sao lại phải làm một việc lặp lại hai lần nhỉ Nếu chỉ giới hạn trong việc giao tiếp giữa các nhà phát triển với nhau thì cá nhân tôi không biết liệu tài liệu có quan trọng đến thế không

😄 Hong : Cảm thấy thật bế tắc, sao không thể cứ nhìn vào file .proto giống như gRPC rồi phát triển theo hướng DDD nhỉ

😁Người phỏng vấn Kakao (Nhà phát triển) : Bạn đã trưởng thành rồi đấy, kẻ tầm thường ạ... kkkkkk đùa thôi, thực ra tôi thấy những gì bạn nói cũng không hẳn là sai đâu

😁Người phỏng vấn Kakao (Nhà phát triển) : Ngày xưa tôi cũng vậy, vì mọi người đều làm thế nên tôi cũng làm y hệt, nhưng trong lúc làm tôi vẫn luôn thắc mắc là "Tại sao lại phải làm thế này nhỉ??". Chính nhờ việc theo đuổi những thứ khác biệt đó mà tôi nghĩ mình đã trưởng thành hơn đấy.

😁 Nhà phát triển Toss : Kkkk Hong thật là tầm thường... kkkkk Vì lý do đó nên mới có GraphQL mà, hình như là do Facebook tạo ra đúng không?

😁Người phỏng vấn Kakao (Nhà phát triển) : Ừ, vậy nên khi tìm hiểu tôi cũng đã sử dụng nó khá nhiều, đúng như Hong nói thì nó giống hệt gRPC vậy, thực chất cảm giác như là đang tiến hành quy chuẩn hóa giao thức truyền thông HTTP vậy

😁Người phỏng vấn Kakao (Nhà phát triển) : Để tôi giải thích cho cái này ㅋㅋㅋㅋ Sẵn tiện đang nói chuyện, với tư cách là một người đã quá quen thuộc với GraphQL, tôi lại muốn thử động vào nó một chút sau một thời gian dài

Làm thế nào để việc viết tài liệu đặc tả – điều mà các nhà phát triển thường né tránh – có thể giúp giảm bớt chi phí giao tiếp trong quá trình trao đổi giữa các lập trình viên với nhau? ⚡

Trong môi trường mà vô số dịch vụ được kết nối xoay quanh dữ liệu, chúng ta không chỉ dừng lại ở việc thiết kế REST API đơn thuần mà còn phải trăn trở về chính việc “làm thế nào để truyền tải và tiêu thụ dữ liệu”.

Ở phía backend, dữ liệu đã chuẩn bị sẵn được gửi xuống, nhưng phía frontend lại nhận về cả những trường không cần thiết, hoặc ngược lại, tình trạng phải gọi lại nhiều API chỉ để cấu thành một màn hình duy nhất cứ lặp đi lặp lại.

Chính vì vậy, những trăn trở như thế này đương nhiên sẽ nảy sinh.

  1. Tại sao không thể chỉ yêu cầu những dữ liệu cần thiết thôi nhỉ??

  2. Cấu trúc mà phiên bản API cứ tiếp tục tăng lên như thế này liệu có thực sự đúng không??

  3. Tại sao vấn đề tài liệu đặc tả Swagger và cấu trúc phản hồi thực tế không khớp nhau cứ lặp đi lặp lại vậy nhỉ??

  4. Liệu frontend và backend có thể cộng tác linh hoạt hơn xoay quanh dữ liệu không??

GraphQL xuất phát từ chính những trăn trở này.

Đây không chỉ đơn thuần là một công nghệ thay thế REST, mà là một cách tiếp cận thiết kế lại chính vai trò của API theo hướng cho phép client trực tiếp định nghĩa và lấy dữ liệu cần thiết. Tôi sẽ cho bạn biết lý do tại sao GraphQL lại ra đời trong thực tế công việc,
nó mạnh mẽ hơn REST trong những tình huống nào, đồng thời cùng nhau xem xét các vấn đề cấu trúc chắc chắn sẽ gặp phải trong thực tế vượt xa mức độ CRUD đơn thuần như thiết kế Schema, cấu trúc Resolver, giải quyết vấn đề N+1, sử dụng DataLoader, Federation, Subscription và xử lý xác thực.

Tôi sẽ giúp bạn thông qua khóa học này để bạn không chỉ là một “lập trình viên biết cú pháp GraphQL” mà có thể trở thành một “lập trình viên có khả năng thiết kế cấu trúc API lấy dữ liệu làm trung tâm”. 🚀

TypeScript, JavaScript, GraphQL, MSA, Bootcamp hỗ trợ từ chính phủ

GraphQL không chỉ đơn thuần là một công nghệ API. ⚡

Trong cấu trúc dựa trên REST truyền thống, khi dữ liệu cần thiết cho mỗi màn hình thay đổi, số lượng API cũng sẽ tăng lên tương ứng.
Khi các trang Web, Mobile và Admin bắt đầu yêu cầu các dữ liệu khác nhau, phía backend cuối cùng sẽ phải liên tục thêm các API tương tự nhau và cấu trúc sẽ ngày càng trở nên phức tạp.


Tuy nhiên, GraphQL lại tiếp cận theo một cách hơi khác.

Client trực tiếp định nghĩa “dữ liệu nào là cần thiết”, và server sẽ kết hợp rồi phản hồi đúng những dữ liệu được yêu cầu đó. Nói cách khác, server không thiết kế API dựa trên màn hình, mà hoạt động tập trung vào chính cấu trúc dữ liệu.


Ngoài ra, GraphQL không chỉ nhìn vào một cơ sở dữ liệu duy nhất.

Các nguồn dữ liệu khác nhau như User Database, Post Database, API bên ngoài, hệ thống Comment, v.v. có thể được kết nối một cách hữu cơ dưới một Schema duy nhất. Nhờ đó, phía Frontend có thể lấy được dữ liệu cần thiết chỉ với một Endpoint duy nhất mà không cần biết cấu trúc bên trong.


Như đã đề cập, khóa học này không chỉ đơn thuần giải thích về cú pháp Query.

Chúng ta sẽ cùng tìm hiểu về vai trò thực sự của Resolver là gì,
tại sao cần đến DataLoader,
tại sao vấn đề N+1 lại xảy ra,
và cả cách phát triển Schema khi quy mô dịch vụ ngày càng lớn.


Bạn sẽ không chỉ đơn thuần học “cách sử dụng GraphQL”, mà còn được rèn luyện tư duy về cách thiết kế và kết nối dữ liệu trong các môi trường dịch vụ phức tạp. 🚀

Tuy nhiên, GraphQL cũng không phải là vạn năng. ⚡

Nhiều nhà phát triển ban đầu tiếp cận GraphQL chỉ đơn thuần là một "công nghệ API tiện lợi hơn REST".

Tuy nhiên, trong môi trường dịch vụ thực tế, bạn sẽ đối mặt với nhiều vấn đề đa dạng hơn mong đợi.

  1. Cấu trúc gọi hàm ngày càng phức tạp khi số lượng Resolver tăng lên,

  2. Vấn đề N+1 phát sinh chỉ vì một Query được viết vô ý

  3. Schema trở nên quá đồ sộ,

  4. Xử lý quyền hạn và chiến lược bộ nhớ đệm,

  5. Cho đến thiết kế Federation trong môi trường MSA

Cuối cùng, điều quan trọng không phải là “cú pháp GraphQL”, mà là quan điểm về cách thiết kế luồng dữ liệu như thế nào. 🚀

Xem trước nội dung bài giảng thực tế 🍡

Di chuyển dữ liệu và GUI sử dụng Prisma

Mô hình DataLoader để ngăn chặn vấn đề N+1, vấn đề nghiêm trọng nhất của Database

Mẫu Subscription dành cho giao tiếp bất đồng bộ và sự kiện (PubSub)

Sơ yếu lý lịch của người phỏng vấn tại Kakao, người đã cùng chuẩn bị bài giảng này 🤭

Tôi là Choi, một nhà phát triển máy chủ backend với 12 năm kinh nghiệm, hiện đang làm việc tại Kakao với vai trò phát triển máy chủ và cũng là người phỏng vấn tuyển dụng.

Tôi đã có cơ hội kết duyên với Hong tại một buổi Conference trước đây, và từ giữa quá trình hoạt động giảng dạy, tôi đã liên tục tham gia tích cực cùng nhau để tạo ra các bài giảng với nhiều chủ đề đa dạng. Tôi tin rằng việc vừa xây dựng các bài giảng vừa đối thoại và giao tiếp với nhiều người như thế này đã giúp ích rất nhiều cho cuộc đời làm nhà phát triển của mình, đồng thời là khoảng thời gian để tôi học hỏi được nhiều góc nhìn khác nhau, vì vậy tôi đang nỗ lực để khai thác thêm nhiều chủ đề đa dạng hơn nữa.

Tôi không nghĩ rằng một lý lịch làm việc tại cái gọi là "tập đoàn lớn" có thể chứng minh ai đó là một nhà phát triển giỏi, nhưng ít nhất tôi tin rằng nơi đó mang lại cơ hội trải nghiệm lưu lượng truy cập (traffic) và kinh nghiệm nhiều hơn so với các nền tảng thông thường. Tôi sẽ luôn cố gắng lồng ghép và truyền đạt những khía cạnh này vào trong các bài giảng của mình.

[Hiện tại] Nhà phát triển máy chủ tại trụ sở chính Kakao

[Cựu] Sinh viên chuyên ngành Kỹ thuật máy tính hệ 4 năm tại Seoul

Môi trường thực hành

  • Hệ điều hành :

    Apple M3 Air

  • Node : v25.5.0

  • IDE : VsCode

Khuyến nghị cho
những người này

Khóa học này dành cho ai?

  • Những nhà phát triển backend luôn cảm thấy "Tại sao mình lại phải làm cùng một việc tận hai lần?" mỗi khi công việc chỉnh sửa Swagger và khớp với tài liệu API cứ lặp đi lặp lại.

  • Nhà phát triển đang mệt mỏi vì phải liên tục điều chỉnh đặc tả dữ liệu với frontend trong khi gọi nhiều REST API chỉ để tạo ra một màn hình duy nhất.

  • Những nhà phát triển đã xem qua cú pháp GraphQL một chút, nhưng vẫn chưa nắm rõ cấu trúc Resolver thực tế hay phương pháp thiết kế trong dự án thực tế.

  • Nhà phát triển máy chủ đang trăn trở về cách kết nối và quản lý luồng dữ liệu trong môi trường MSA hoặc cấu trúc dịch vụ quy mô lớn.

  • Một nhà phát triển muốn trưởng thành bằng cách thấu hiểu "Tại sao công nghệ này lại ra đời và nó đang cố gắng giải quyết vấn đề gì?" thay vì chỉ đơn thuần là cách sử dụng kỹ thuật.

Cần biết trước khi bắt đầu?

  • Đây là bài giảng dành cho người mới bắt đầu! Vì độ khó thấp nên không yêu cầu kiến thức tiên quyết.

Xin chào
Đây là Hong

Xác minh Inflearn

Xác minh sự nghiệp

9,462

Học viên

585

Đánh giá

157

Trả lời

4.7

Xếp hạng

32

Các khóa học

Giới thiệu bản thân

Tôi bắt đầu học lập trình sau một thời gian dài lười biếng ở nhà và cảm thấy hứng thú với nó, hiện tại tôi đang đảm nhận việc phát triển máy chủ nền tảng (platform server) tại Pangyo. Tôi tiếp tục hoạt động với tư cách là người chia sẻ kiến thức vì muốn cung cấp cho các bạn phương pháp tôi đã học cũng như những vấn đề và giải pháp thực tế mà các bạn có thể gặp phải trong công việc.

 

Bài giảng không chỉ được tạo ra từ kiến thức của riêng tôi. Mọi bài giảng đều có sự đồng hành của tất cả các bạn.

 

Kinh nghiệm của người chia sẻ kiến thức

[Trước đây] Nhà phát triển Blockchain liên quan đến Sandbox IP

[Cựu] Nhà phát triển Backend Metaverse

[Hiện tại] Nhà phát triển server đang làm việc lâu năm tại Pangyo

 

Lịch sử phỏng vấn

Các câu hỏi khác

  • unduck2022@gmail.com

Chương trình giảng dạy

Tất cả

16 bài giảng ∙ (3giờ 58phút)

Tài liệu khóa học:

Tài liệu bài giảng
Ngày đăng: 
Cập nhật lần cuối: 

Đánh giá

Chưa có đủ đánh giá.
Hãy trở thành tác giả của một đánh giá giúp mọi người!

Ưu đãi có thời hạn

655.554 ₫

59%

1.609.087 ₫

Khóa học khác của Hong

Hãy khám phá các khóa học khác của giảng viên!

Khóa học tương tự

Khám phá các khóa học khác trong cùng lĩnh vực!