Lấy Dữ Liệu Với GraphQL: Một Cách Tiếp Cận Hiện Đại Đối Với APIs

Trong khi REST APIs là cách truyền thống để các ứng dụng và trang web giao tiếp với máy chủ yêu cầu và nhận dữ liệu theo các quy tắc đã định, GraphQL, một đổi mới của Facebook vào năm 2012, cho phép các ứng dụng xác định chính xác nhu cầu dữ liệu của mình, có thể lấy thông tin một cách hiệu quả hơn.

GraphQL là gì?

GraphQL https://graphql.org/ là một ngôn ngữ truy vấn cho APIs (Giao diện lập trình ứng dụng). Hãy nghĩ về nó như một cách để các ứng dụng yêu cầu chính xác dữ liệu họ cần từ máy chủ.

Ai đang sử dụng GraphQL?

• Microsoft Corporation
• Amazon Web Services, Inc.
• Atlassian US, Inc.
• Shopify Inc.
• International Business Machines Corporation
• Airbnb
• Starbucks
• và nhiều hơn nữa https://landscape.graphql.org/borderless-mode?grouping=category

Nó khác biệt như thế nào so với cách truyền thống?

Truy vấn dữ liệu chính xác

• Truyền thống: Bạn nhận được một tập dữ liệu cố định, đôi khi nhiều hơn những gì bạn cần.
• GraphQL: Bạn yêu cầu chỉ những gì bạn muốn, không nhiều hơn, không ít hơn.

Truyền thống REST API:

GET /users/123
Response: { "id": 1, "name": "Huan Vu", "email": "[email protected]", "phone": "+84877698945", "address": "Gia Nghia, Dak Nong, Viet Nam" }

GraphQL:

query {
  user(id: 1) {
    name
    email
  }
}
Response: { "data": { "user": { "name": "Huan Vu", "email": "[email protected]" } } }

Trong ví dụ này, GraphQL chỉ truy vấn tên và email, trong khi REST API trả về toàn bộ dữ liệu người dùng.

Yêu cầu đơn lẻ

Truyền thống: Bạn có thể cần nhiều yêu cầu để lấy tất cả dữ liệu bạn cần.

GET /users/123
GET /users/123/posts
GET /users/123/friends

GraphQL: Một yêu cầu có thể lấy dữ liệu từ nhiều nguồn.

query {
  user(id: 123) {
    name
    posts {
      title
    }
    friends {
      name
    }
  }
}

Truy vấn GraphQL này lấy dữ liệu người dùng, bài viết và bạn bè trong một yêu cầu.

Hiệu suất nhanh hơn

• Truyền thống: Nhiều dữ liệu truyền tải hơn dẫn đến thời gian tải chậm hơn.
• GraphQL: Ít dữ liệu không cần thiết hơn có nghĩa là ứng dụng nhanh hơn.

Dễ dàng cập nhật

Truyền thống:

• Thay đổi trong cấu trúc dữ liệu có thể làm hỏng ứng dụng. Trong REST, cấu trúc của phản hồi là cố định. Nếu bạn thay đổi cấu trúc dữ liệu trên máy chủ, tất cả các khách hàng mong đợi cấu trúc cũ có thể bị hỏng.
• Việc loại bỏ hoặc thay đổi các trường thường yêu cầu tạo phiên bản API mới. APIs thường cần phiên bản hóa (ví dụ: /api/v1/, /api/v2/) để duy trì tính tương thích ngược.
• Thêm một trường cho một khách hàng cụ thể có thể ảnh hưởng đến tất cả các khách hàng. Những thay đổi đáng kể thường yêu cầu cập nhật toàn bộ API và tất cả khách hàng đồng thời.

GraphQL:

• Nó linh hoạt hơn, cho phép cập nhật dễ dàng mà không làm hỏng mọi thứ.
• Bạn có thể đánh dấu các trường là không còn sử dụng. Các khách hàng có thể được thông báo về các trường không còn sử dụng nhưng vẫn có thể sử dụng chúng, cho phép chuyển đổi mượt mà. Bạn có thể thêm các trường và kiểu mới mà không cần tạo phiên bản mới. Các truy vấn cũ vẫn hoạt động và các truy vấn mới có thể sử dụng các trường mới.
• Các trường mới có thể được thêm mà không ảnh hưởng đến các khách hàng khác. Chỉ những truy vấn yêu cầu trường mới sẽ nhận được nó. Các tính năng mới có thể được thêm vào từng bước. Các khách hàng có thể áp dụng các trường mới theo tốc độ riêng của họ.

Tự động tài liệu hóa

Truyền thống:

• Bạn cần tài liệu riêng biệt (như Swagger hoặc API blueprints) để hiểu API.
• Tài liệu có thể trở nên lỗi thời nếu không được duy trì cẩn thận.
• Các nhà phát triển cần chuyển đổi giữa tài liệu và mã.
• Hiểu dữ liệu có sẵn và các mối quan hệ có thể là một thách thức.

GraphQL:

• Bản schema tự nó mô tả dữ liệu có sẵn.
• Cung cấp khả năng introspection tích hợp để khám phá API. Các APIs GraphQL hỗ trợ introspection https://graphql.org/learn/introspection/, cho phép khách hàng truy vấn bản schema tự nó.
• Các công cụ có thể tự động tạo tài liệu từ bản schema.
• Xác định rõ ràng các kiểu, trường và mối quan hệ.

Truy vấn dữ liệu

• GraphQL có thể truy vấn dữ liệu từ nhiều nguồn khác nhau. Dữ liệu cho GraphQL có thể đến từ các cơ sở dữ liệu (MySQL, PostgreSQL, MongoDB, Cassandra, v.v.), các APIs hiện có (REST APIs, dịch vụ SOAP, v.v.).
• Điểm chính là GraphQL hoạt động như một lớp giữa khách hàng và các nguồn dữ liệu này. Máy chủ GraphQL xử lý sự phức tạp của việc truy vấn dữ liệu từ nhiều nguồn và trình bày nó theo cách thống nhất cho khách hàng.
• Để sử dụng các nguồn dữ liệu này với GraphQL, các nhà phát triển thường tạo ra "resolvers" - các hàm xác định cách truy vấn dữ liệu cho mỗi trường trong bản schema GraphQL. Điều này cho phép GraphQL linh hoạt và làm việc với hầu hết các loại nguồn dữ liệu.

Nhược điểm của GraphQL

Dù GraphQL mang lại nhiều lợi ích, nó cũng có một số nhược điểm. Dưới đây là một số nhược điểm chính:

• Phức tạp cho các ứng dụng đơn giản:
  • Đối với các thao tác CRUD cơ bản hoặc APIs đơn giản, GraphQL có thể là quá mức cần thiết.
  • Thiết lập GraphQL yêu cầu nhiều công việc ban đầu hơn so với một REST API đơn giản.
• Quan ngại về hiệu suất với truy vấn lồng nhau:
  • Các truy vấn lồng nhau sâu có thể dẫn đến các vấn đề hiệu suất nếu không được tối ưu hóa đúng cách.
  • Nguy cơ vấn đề N+1 truy vấn nếu các resolvers không được triển khai hiệu quả.
• Thách thức về caching:
  • Các phương pháp caching HTTP truyền thống không hoạt động tốt với cách tiếp cận endpoint đơn của GraphQL.
  • Việc triển khai caching hiệu quả yêu cầu các giải pháp phức tạp hơn.
• Khả năng lấy quá nhiều dữ liệu ở backend:
  • Dù các khách hàng chỉ có thể yêu cầu những gì họ cần, các resolvers vẫn có thể lấy nhiều dữ liệu hơn cần thiết từ cơ sở dữ liệu.
• Đường cong học tập:
  • Các đội ngũ quen thuộc với REST APIs cần thời gian để thích nghi với các khái niệm của GraphQL.
  • Yêu cầu học các công cụ và thực hành tốt nhất mới.
• Quá tải cho các truy vấn đơn giản:
  • Ngay cả các truy vấn đơn giản cũng yêu cầu quá trình phân tích và xác nhận đầy đủ của GraphQL.
  • Điều này có thể thêm quá tải không cần thiết cho các nhu cầu truy vấn dữ liệu rất cơ bản.

Những nhược điểm này không làm cho GraphQL trở thành một lựa chọn tồi - nó vẫn rất tuyệt vời cho nhiều trường hợp sử dụng. Tuy nhiên, chúng là những cân nhắc quan trọng khi quyết định sử dụng GraphQL cho một dự án.

Sử dụng GraphQL trong các dự án của bạn

• Ruby on Rails https://graphql-ruby.org/getting_started
• NodeJS https://graphql.org/graphql-js/running-an-express-graphql-server/
• PHP Laravel https://github.com/rebing/graphql-laravel