1. Giới thiệu chung

1.1 GraphQL là gì?

GraphQL là ngôn ngữ thao tác và truy vấn dữ liệu nguồn mở cho API, cung cấp cho client 1 cách thức dễ dàng để request chính xác những gì họ cần, giúp việc phát triển API dễ dàng hơn theo thời gian. GraphQL được Facebook phát triển nội bộ vào năm 2012 trước khi phát hành công khai vào năm 2015.

GraphQL bao gồm 3 điểm đặc trưng bao gồm:

• Cho phép client xác định chính xác những dữ liệu gì họ cần
• GraphQL làm cho việc tổng hợp dữ liệu từ nhiều nguồn dễ dàng hơn
• Sử dụng một type system để khai báo dữ liệu.

1.2 REST là gì?

REST (Representational State Transfer) là một kiến trúc thiết kế web dựa trên giao thức HTTP (Hypertext Transfer Protocol). REST được sử dụng để xây dựng các ứng dụng web đáp ứng được các yêu cầu về khả năng mở rộng, bảo mật và tính tương thích giữa các hệ thống khác nhau.

REST sử dụng các định dạng dữ liệu chuẩn như XML (Extensible Markup Language) và JSON (JavaScript Object Notation) để truyền tải dữ liệu giữa các máy khách và máy chủ. REST cũng có các nguyên tắc thiết kế để đảm bảo tính linh hoạt và dễ dàng bảo trì, bao gồm việc sử dụng các phương thức HTTP chuẩn như GET, POST, PUT, DELETE để thao tác với tài nguyên trên máy chủ.

• Trải qua nhiều thập kỉ, REST đã trở thành một tiêu chuẩn cho thiết kế Web API. REST có những ý tưởng rất tuyệt vời như là stateless servers hay là structured access to resources.
• Tuy nhiên REST APIs vẫn còn chưa linh hoạt để bắt kịp với những yêu cầu thay đổi nhanh chóng phía client.
• GraphQL được phát triển để đáp ứng nhu cầu linh hoạt hơn và hiệu quả hơn. Nó giải quyết nhiều những thiếu sót và kém hiệu quả mà developer đã trải nghiệm được sau một thời gian làm việc với REST API.

2. Ưu điểm của GraphQL so với REST

2.1 Data Fetching với GraphQL và REST

Để làm rõ sự khác nhau giữa REST và GraphQL khi fetching data từ API, chúng ta hãy xem xét một kịch bản đơn giản sau: Với một ứng dụng blog, ứng dụng sẽ cần hiển thị list tiêu đề các bài post của một user cụ thể. Cùng màn hình đó, bạn cũng cần phải hiển thị tên của 3 followers của user đó. Hãy cùng xem cách mà REST và GraphQL xử lý.

2.1.1 Multiple Endpoint và Single Endpoint

• Với REST API, bạn sẽ lấy data bằng việc sử dụng nhiều endpoint. Với kịch bản trên, Bạn sẽ sử dụng 1 endpoint /users/<id> để lấy dữ liệu của user. Sau đó bạn sẽ sử dụng 1 endpoint nữa là /user/<id>/posts để lấy tất cả các bài post của user. Endpoint thứ ba sẽ là /user/<id>/followers trả về danh sách các follower của user.

• Với GraphQL, bạn chỉ cần đơn giản gửi một câu query tới GraphQL Server bao gồm các yêu cầu dữ liệu cụ thể. Server sẽ trả về một JSON object đáp ứng các yêu cầu client gửi lên. Chú ý rằng Cấu trúc response mà Server trả về sẽ tuân theo chính xác cấu trúc lồng nhau mà được chỉ định trong query gửi lên từ Client.

2.1.2 GraphQL giải quyết Overfetching và Underfetching

Một vấn đề thông thường nhất gặp phải với REST là Overfetching và Underfetching. Điều này xảy ra do Client sử dụng endpoint để lấy dữ liệu về, và các endpoint thì trả về cấu trúc dữ liệu cố định. Điều này dẫn đến những khó khăn cho việc thiết kế API làm thế nào để có thể cung cấp cho client chính xác những gì mà client cần.

• Overfetching: Trả về dư thừa dữ liệu cho ClientOverfetching có nghĩa là một Client lấy được nhiều thông tin hơn so với những gì nó cần. Ví dụ dễ hiểu một màn hình cần hiển thị danh sách các user chỉ với tên của các user đó. Nhưng với REST API, bạn gọi endpoint /users và nhận về mảng JSON các dữ liệu của user. Response có thể chứa nhiều thông tin của user như ngày sinh, địa chỉ của user…, những thông này vô dụng với client vì client chỉ cần hiển thị tên của các user.
• Underfetching và vấn đề n+1Underfetching có nghĩa là một endpoint cụ thể không cung cấp đủ thông tin yêu cầu cho client. Client phải thực hiện thêm những request khác để lấy thêm dữ liệu mà nó cần. Khi đó vấn đề n+1 xảy ra khi mà đầu tiên Client cần lấy về một list các phần tử, nhưng sau đó đối với mỗi phần tử lại phải tạo một request để lấy dữ liệu yêu cầu của mỗi phần tử!Ví dụ với kịch bản ứng dụng cần hiển thị list user, và mỗi user cần hiển thị 3 followers gần nhất. Đầu tiên ứng dụng cần phải gọi 1 endpoint /users và sau đó ứng với mỗi user, chúng ta phải thực hiện một endpoint bổ sung là /users/<user-id>/followers

Với việc sử dụng 1 endpoint, cho phép client chỉ định những dữ liệu nào mà client cần, server trả về đúng dữ liệu theo cấu trúc lồng nhau được chỉ định trong query của client thì GraphQL đã giải quyết được vấn đề Overfetching và Underfetching.

2.1.3 Imperative data fetching và Declarative Data Fetching

• REST theo phương pháp Imperative data fetching (Tìm nạp dữ liệu mệnh lệnh). Khi fetching data từ REST API, một ứng dụng cần phải thực hiện các bước sau:
  1. Gửi dữ liệu HTTP request (vd fetch trong javascript)
  2. Nhận và parse dữ liệu nhận được từ server.
  3. Store dữ liệu dưới local.
  4. Hiển thị dữ liệu trên UI
• GraphQL tiếp cận theo ý tưởng declarative data fetching (Tìm nạp dữ liệu khai báo), Client chỉ việc thực hiện 2 bước sau:
  1. Mô tả yêu cầu dữ liệu.
  2. Hiển thị dữ liệu trên UI.

  Cách tiếp cận này tập trung vào việc Client sẽ khai báo dữ liệu (declarative data), còn trừu tượng hóa các tác vụ khác cũng như việc lưu trữ dữ liệu.

2.2 Vấn đề đáp ứng sự thay đổi nhanh chóng phía Client.

• Với REST API, Client sẽ gọi các endpoint tương ứng cho các view, server sẽ trả về tất cả các thông tin được yêu cầu cho một view cụ thể. Tuy nhiên điểm yếu của REST API ở chỗ này là nó sẽ không đáp ứng nhanh chóng sự thay đổi phía Client. Với mỗi sự thay đổi phía UI (chẳng hạn như yêu cầu nhiều dữ liệu hơn), thì phía backend (server) cũng phải thay đổi để đáp ứng yêu cầu dữ liệu mới. Nó sẽ làm giảm hiệu suất, và chậm việc update product liên tục.
• Với GraphQL, vấn đề này đã được giải quyết. Nhờ có sự linh hoạt phía GraphQL, sự thay đổi phía Client sẽ không dẫn đến phải thay đổi phía server, bởi client có thể chỉ định chính xác yêu cầu dữ liệu mà client cần, do đó chỉ việc thay đổi phía Client.

2.3 Độ phụ thuộc giữa Backend và Frontend

– Lợi thế của Schema và Type của GraphQL

• GraphQL sử dụng hệ thống Type và sử dụng Schema Definition Language (SDL) để định nghĩa Schema. Hãy hiểu Schema như là một hợp đồng giữa Client và Server, một bản mô tả cách mà client có thể lấy dữ liệu trên Server.
• Một khi Schema đã được định nghĩa, team frontend và team backend có thể làm việc độc lập và không cần trao đổi với nhau nhiều vì cả 2 bên đã biết được cấu trúc dữ liệu sẽ được transfer như nào.
• Team Frontend có thể tạo dummy test data để test ứng dụng và khi server đã sẵn sàng, team frontend sẽ chuyển sang lấy dữ liệu từ API thực tế. Điều này giúp tăng hiệu suất làm việc rất nhiều.

2.4 Phân tích sự dư thừa dữ liệu

• Với REST API, chúng ta có toàn bộ dữ liệu được trả về trong một API endpoint, như vậy chúng ta sẽ không biết được thông tin về việc sử dụng các trường dữ liệu cụ thể.
• Đối với GraphQL, chúng ta sẽ chỉ định chính xác những gì chúng ta cần, như vậy chúng ta sẽ biết được trường dữ liệu nào đang được sử dụng và trường dữ liệu nào không được request từ Client nữa.
• Hơn nữa, GraphQL sử dụng resolver function để xử lý dữ liệu mà client yêu cầu. Các phương pháp đo lường hiệu suất cho các resolvers sẽ giúp bạn nhìn thấy được những chỗ “cổ chai” trong ứng dụng của bạn, giúp bạn có thể theo dõi được performance của hệ thống.

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

• GraphQL luôn trả về HTTP status code là 200, bất kể query có success hay không. Nếu query fail, JSON response trả về sẽ có key errors, với các error message và stacktrace. Điều này gây khó khăn hơn trong việc error handling.
• Phải thiết kế Schema trước, sẽ vất vả hơn vì thêm việc mặc dù sau này schema sẽ giúp bạn ngăn chặn nhiều lỗi và đỡ tốn sức hơn khi nâng cấp.
• Khi Client không cần quan tâm đến data lấy từ đâu thì Sự phức tạp được đẩy về phía server, GraphQL không phải là giải pháp tốt cho các ứng dụng đơn giản.
• Vấn đề caching. REST API sử dụng nhiều endpoint nên nó tận dùng HTTP caching để tránh việc phải tìm nạp lại tài nguyên. Với GraphQL, nó sử dụng 1endpoint thay vì theo cơ chế caching của HTTP. Lưu vào bộ nhớ đệm là rất quan trọng vì nó làm giảm sự truy cập vào máy chủ. Với GraphQL, bạn phải sử dụng thư viện khác phía Client để đáp ứng việc caching.

4. Kết luận

• Bài viết trên mình đã trình bày sự khác nhau giữa REST và GraphQL qua những ưu nhược điểm của GraphQL so với REST. Cả REST và GraphQL đều là những cách nổi bật để thiết kế API.
• REST đơn giản hóa đáng kể công việc của dev với cách tiếp cận tiêu chuẩn, tuy nhiên nó cũng có vài nhược điểm.
• GraphQL giải quyết những nhược điểm của REST và có nhiều ưu điểm vượt trội hơn so với REST, tuy nhiên không phải lúc nào nó cũng là giải pháp tốt nhất.
• Đối với những ứng dụng xử lý dữ liệu tương đối nhất quán, mình nghĩ nên sử dụng REST API. Còn đối với những ứng dụng mà cần xử lý với dữ liệu thay đổi nhanh chóng, yêu cầu update product liên tục thì hãy trải nghiệm với GraphQL.
• Dù sao, bạn có thể sử dụng cả REST và GraphQL trong 1 project. Hãy phân tích ứng dụng của bạn và yêu cầu hiệu suất để có lựa chọn thích hợp nhé.

Hy vọng với toàn bộ những thông tin triển khai chia sẻ trên đã giúp bạn đọc biết rõ về sự khác nhau giữa REST và GraphQL qua những ưu nhược điểm của GraphQL so với REST. Cả REST và GraphQL đều là những cách nổi bật để thiết kế API.

Bạn có thể tham khảo thêm về các bài viết về hóa đơn điện tử và chữ ký số tại đây

P.A Việt Nam cung cấp dịch vụ Hóa Đơn Điện Tử CHỈ TRONG 30S NHANH CHÓNG | TIẾT KIỆM | AN TOÀN

https://hoadon30s.vn/

Hiện tại chúng tôi cũng có 1 số chương trình khuyến mãi cho các dịch vụ các bạn cũng có thể tham khảo tại đây

Hãy liên hệ với Pavietnam khi bạn cần tư vấn nhé!

P.A Việt Nam – Nhà đăng ký Tên miền trực thuộc VNNIC, được tổ chức Tên miền quốc tế ICANN công nhận. Nhà cung cấp Hosting, Máy Chủ Server lớn nhất Việt Nam.

Chúng tôi luôn hướng đến các dịch vụ tốt nhất cho khách hàng: dễ đặt mua, thanh toán nhanh, toàn quyền quản lý và điều chỉnh các tùy chọn theo ý muốn…