inflearn logo

GraphQL cho các mẫu 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 chỉnh sửa tài liệu Swagger, khớp đặc tả API và liên tục trao đổi 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 từng cảm thấy bế tắc tương tự trong công việc thực tế, và thông qua quá trình đó, tôi đã tìm hiểu sâu về 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ỉ dừng lại ở cú pháp GraphQL đơn thuần, mà còn đi sâu vào việc nó ra đời để giải quyết vấn đề gì trong các dịch vụ thực tế, cùng những trăn trở thực tiễn như 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ể giảm thiểu chi phí giao tiếp giữa các nhà phát triển và nắm bắt một cách tự nhiên quy trình thiết kế cấu trúc API linh hoạt hơn.

(5.0) 2 đánh giá

85 học viên

Độ 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 theo cấu trúc như thế này?”.

  • Thông qua việc trực tiếp giải quyết các vấn đề Over Fetching / Under Fetching thường lặp lại trong REST API, bạn sẽ được trải nghiệm cách Frontend và Backend có thể cộng 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 đế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à một 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, bạn sẽ hiểu được cấu trúc tự tạo tài liệu dựa trên Introspection và có cái nhìn mới về chính phương thức lập tài liệu API.

  • Vượt qua mức CRUD đơn giản, bằng cách học các mô hình nâng cao như Federation, Subscription và xử lý xác thực, bạn sẽ có thể hiểu được quy trình mở rộng GraphQL trong các 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?? Mấy cái này là gì thế??

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

😄 Hong : Ở công ty, thật sự là ngay cả khi chỉ phát triển một API thôi cũng thấy rất phiền vì họ yêu cầu Swagger quá nhiều... Cứ phải khớp định dạng rồi mỗi khi spec thay đổi lại phải sửa theo nên thấy phiền phức lắm.

😄 Hong : Lúc nào tôi cũng cảm thấy thế nà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 trùng lặp hai lần nhỉ Nếu chỉ giới hạn ở 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ó thực sự quan trọng đến thế không

😄 Hong : Cứ nhìn file .proto rồi phát triển theo kiểu DDD như gRPC không được sao, thấy bực ghê

😁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 điều đó cũng không hẳn là sai đâu

😁Người phỏng vấn Kakao (Nhà phát triển) : Trước đây 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 khi làm tôi vẫn luôn thắc mắc là "Tại sao lại làm thế này nhỉ??" Và rồi khi tìm kiếm những cách khác, tôi cảm thấy mình đã trưởng thành hơn?

😁 Nhà phát triển Toss : Hahaha Hong phàm phu à... kkkkk Đó là lý do tại sao có GraphQL mà, hình như Facebook tạo ra nó đúng không?

😁Người phỏng vấn Kakao (Developer) : Ừ, vậy nên trong quá trình 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ề cơ bản cảm giác như là việc chuẩn hóa giao tiếp HTTP để thực hiện vậy

😁Người phỏng vấn Kakao (Developer) : Để mình giải thích cho kkkk. Nhân tiện đang nói về chuyện này, với tư cách là một "lão làng" GraphQL, mình lại muốn thử động vào nó sau một thời gian dài đấy

Làm thế nào để giảm thiểu chi phí giao tiếp giữa các lập trình viên trong việc viết tài liệu đặc tả (spec), một công việc mà họ thường né tránh? ⚡

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 trăn trở về chính “việc làm thế nào để truyền tải và tiêu thụ dữ liệu”.

Trong khi phía backend trả về dữ liệu đã được chuẩn bị sẵn, phía frontend đôi khi phải nhận cả những trường không cần thiết, và ngược lại, tình trạng phải gọi nhiều API cùng lúc chỉ để hiển thị một màn hình duy nhất cũng thường xuyên xảy ra.

Chính vì vậy, những băn khoăn này nảy sinh một cách tự nhiên.

  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. Liệu cấu trúc mà các phiên bản API cứ liên tục tăng lên như thế này có thực sự đúng đắn không??

  3. Tại sao vấn đề sai lệch giữa tài liệu đặc tả Swagger và cấu trúc phản hồi thực tế lại cứ lặp đi lặp lại??

  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 bắt đầu chính từ nhận thức về vấn đề này.

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

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

TypeScript, JavaScript, GraphQL, MSA, Bootcamp hỗ trợ bởi 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 càng khác nhau thì số lượng API cũng tăng lên theo.
Khi các trang Web, Mobile và Admin bắt đầu yêu cầu các dữ liệu khác nhau, cuối cùng phía backend sẽ liên tục thêm các API tương tự và cấu trúc sẽ ngày càng trở nên phức tạp.


Tuy nhiên, GraphQL 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ẽ tổng hợp rồi phản hồi chỉ những dữ liệu cần thiết theo yêu cầu đó. Nói cách khác, thay vì server thiết kế API dựa trên màn hình, nó sẽ hoạt động tập trung vào chính cấu trúc dữ liệu.


Ngoài ra, GraphQL không chỉ đơn thuần kết nối với một cơ sở dữ liệu duy nhất.

Bạn có thể kết nối một cách hữu cơ 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. dưới một Schema duy nhất. Nhờ đó, 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ư tôi đã đề 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 vai trò thực sự của Resolver là gì,
tại sao cần DataLoader,
tại sao vấn đề N+1 lại xảy ra,
cho đến 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 cùng nhau rèn luyện tư duy về cách thiết kế và kết nối dữ liệu trong 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 giản như 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 những gì bạn nghĩ.

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

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

  3. Schema trở nên phình to quá mức,

  4. Xử lý phân quyền và chiến lược caching,

  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à góc nhìn về cách thiết kế luồng dữ liệu. 🚀

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 đề chí mạng nhất của Database

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

Hồ sơ của người phỏng vấn Kakao đã cùng chuẩn bị khóa học 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 phát triển máy chủ và cũng hoạt động với tư cách là người phỏng vấn tại Kakao.

Tôi đã có duyên gặp gỡ Hong tại một Conference trước đây, và kể 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 để xây dựng các bài giảng với nhiều chủ đề đa dạng. Tôi tin rằng việc trò chuyện và giao tiếp với nhiều người trong quá trình xây dựng bài giảng như thế này giúp ích rất nhiều cho sự nghiệp lập trình viên của mình và 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ủ đề phong phú hơn nữa.

Tôi không nghĩ rằng việc có kinh nghiệm làm việc tại một "tập đoàn lớn" là minh chứng cho một lập trình viên giỏi, nhưng ít nhất, tôi tin rằng môi trường đó mang lại nhiều trải nghiệm và lưu lượng truy cập lớn hơn so với các nền tảng thông thường. Tôi sẽ luôn lồng ghép những khía cạnh này vào bài giảng để truyền tải đến các bạn.

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

[Cựu] Chuyên ngành Khoa học máy tính hệ 4 năm tại Seoul

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

  • OS :

    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?

  • Lập trình viên backend thường tự hỏi “Tại sao mình lại đang làm cùng một việc hai lần?” mỗi khi công việc chỉnh sửa Swagger và khớp tài liệu API lặp đi lặp lại.

  • Lập trình viên đang kiệt sức vì phải gọi nhiều REST API chỉ để tạo một màn hình và liên tục phải điều chỉnh đặc tả dữ liệu với phía frontend.

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

  • Nhà phát triển server đ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 thông qua việc thấu hiểu “Tại sao công nghệ này ra đời và nó giải quyết vấn đề gì?” thay vì chỉ đơn thuần học cách sử dụng chúng.

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

10,000

Học viên

630

Đánh giá

165

Trả lời

4.7

Xếp hạng

32

Các khóa học

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 khác nhau mà các bạn có thể gặp phải trong thực tế.

 

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 những người cộng sự.

 

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

[Cựu] 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]

[Yêu cầu khác]

[Trang web chính thức]

Thêm

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á

Tất cả

2 đánh giá

5.0

2 đánh giá

  • warna97725274님의 프로필 이미지
    warna97725274

    Đánh giá 13

    Đánh giá trung bình 5.0

    5

    81% đã tham gia

    Có vẻ rất phù hợp để nghe nhẹ nhàng cho người mới bắt đầu. Cảm ơn bạn!

    • jukascrow6433님의 프로필 이미지
      jukascrow6433

      Đánh giá 9

      Đánh giá trung bình 5.0

      5

      88% đã tham gia

      Nếu bạn tò mò về GraphQL, tôi khuyên bạn nên bắt đầu với khóa học này. Tôi cũng từng không biết gì cả, nhưng sau khi nghe bài giảng này, tôi đã nắm bắt được phần nào và đang trong quá trình áp dụng vào thực tế. Xin cảm ơn.

      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!

      Giảm 25% cho thành viên mới

      1.202.434 ₫

      25%

      1.603.244 ₫