Bài viết này sẽ chia sẻ khái niệm và giới thiệu về graphql cho những bạn mới tìm hiểu về nó, chưa từng nghe đến nó hoặc đã nghe đến cái tên graphql nhưng chưa biết gì về nó. Vậy graphql là gì? Hãy cùng tìm hiểu dưới đây.
Khái niệm và giới thiệu chung
- graphql là viết tắt của Graph Query Language do facebook tạo ra vào năm 2012, ngôn ngữ này cung cấp một giao thức chung cho phép giao tiếp giữa máy khách và máy chủ để cập nhật và truy xuất dữ liệu.
- Có thể hiểu đơn giản nó là một cú pháp mô tả cách yêu cầu dữ liệu, cú pháp này thường dùng để tải dữ liệu từ server về client.
- Yêu cầu của bạn đối với graphql được gọi là truy vấn cho phép hỗ trợ các trường lồng nhau trong tất cả các hệ thống của ứng dụng của bạn.
- Vì vậy, khi khách hàng đưa ra yêu cầu và tạo truy vấn, khách hàng không cần lo lắng về việc dữ liệu được tìm nạp từ nguồn nào. Máy chủ graphql sẽ chăm sóc và thực hiện tất cả công việc.
- graphql sử dụng lược đồ làm hợp đồng “tiêu chuẩn ngôn ngữ” giữa máy khách và máy chủ. Máy khách có thể sử dụng định nghĩa trong lược đồ để gửi đến máy chủ để lấy dữ liệu từ máy chủ và máy chủ cũng phụ thuộc vào nó. Từ đó, tôi có thể thấy những gì tôi đã làm và kết quả tôi đã trả lại cho khách hàng.
- graphql có ngôn ngữ riêng để xác định lược đồ. Đó là Ngôn ngữ Định nghĩa Lược đồ (sdl) đột biến
- Ngoài việc yêu cầu dữ liệu từ máy chủ, đôi khi máy khách cần sửa đổi dữ liệu được lưu trữ trong phần phụ trợ. Sử dụng graphql, chúng ta có thể làm điều này bằng cách sử dụng các đột biến. Nhìn chung, có 3 dạng đột biến phổ biến:
- Một biến thể tuân theo cấu trúc cú pháp giống như một truy vấn, nhưng nó luôn phải bắt đầu bằng một biến thể từ khóa. (ví dụ: tạo sách, cập nhật sách, xóa sách,…).
- Đối với tình huống trên, bạn sẽ sử dụng điểm cuối /users/; để tìm nạp dữ liệu người dùng.
- Sau đó, bạn sẽ sử dụng một điểm cuối khác /user//posts để nhận tất cả các bài đăng của người dùng.
- thứ ba là /user//followers, trả về danh sách những người theo dõi của người dùng.
- Với graphql bạn chỉ cần gửi truy vấn đến máy chủ graphql với yêu cầu dữ liệu cụ thể. Máy chủ sẽ trả về một đối tượng json đáp ứng yêu cầu của máy khách. Lưu ý rằng cấu trúc phản hồi do máy chủ trả về sẽ tuân theo chính xác cấu trúc lồng nhau được chỉ định trong truy vấn do máy khách gửi.
- Máy khách sử dụng điểm cuối để truy xuất dữ liệu và điểm cuối trả về cấu trúc dữ liệu cố định.
- Điều này gây khó khăn cho việc thiết kế cách API cung cấp cho khách hàng chính xác những gì họ muốn.
- Việc sử dụng một điểm cuối duy nhất cho phép khách hàng chỉ định trực tiếp dữ liệu họ cần và máy chủ trả về dữ liệu chính xác theo cấu trúc lồng nhau được chỉ định trong truy vấn của khách hàng.
- Trực tiếp giải quyết vấn đề mua quá mức và mua dưới mức.
- Mỗi khi giao diện người dùng thay đổi (ví dụ: yêu cầu thêm dữ liệu), phần phụ trợ (máy chủ) cũng phải thay đổi để đáp ứng yêu cầu dữ liệu mới. Nó làm chậm hiệu suất và làm chậm quá trình cập nhật sản phẩm đang diễn ra.
- Phía graphql có tính linh hoạt, các thay đổi phía máy khách sẽ không gây ra các thay đổi phía máy chủ, bởi vì máy khách có thể chỉ định chính xác dữ liệu mà máy khách cần, vì vậy chỉ cần thay đổi máy khách.
- Tất cả dữ liệu được trả về trong điểm cuối api, vì vậy chúng tôi không biết cách sử dụng các trường dữ liệu cụ thể.
- Chúng tôi sẽ chỉ định chính xác những gì chúng tôi cần để chúng tôi biết trường nào đang được sử dụng và trường nào không còn được yêu cầu từ khách hàng.
- graphql luôn trả về mã trạng thái http là 200, cho dù truy vấn có thành công hay không. Nếu truy vấn không thành công, phản hồi json trả về sẽ có lỗi nghiêm trọng, với thông báo lỗi và dấu vết ngăn xếp. Điều này làm cho việc xử lý lỗi trở nên khó khăn hơn.
- Graphql phải thiết kế lược đồ trước, điều này sẽ khó khăn và tốn thời gian, nhưng về sau, lược đồ sẽ giúp bạn tránh được nhiều lỗi và nâng cấp dễ dàng hơn.
- Khi client không quan tâm dữ liệu đến từ đâu, sự phức tạp dồn 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.
- Sử dụng nhiều điểm cuối, do đó, nó sử dụng bộ nhớ đệm http để tránh tìm nạp lại tài nguyên.
- Cơ chế cache sử dụng điểm cuối thay vì http. Bộ nhớ đệm rất quan trọng vì nó giảm lượt truy cập vào máy chủ. Khi sử dụng graphql, bạn phải sử dụng các thư viện máy khách khác để lưu vào bộ đệm.
graphql được phát triển dựa trên các yếu tố chính sau:
Truy vấn
Cấu trúc
Đột biến
+ tạo mới (new). + cập nhật (cập nhật). + xóa (xóa).
Sau khi đọc những thông tin chi tiết trên chắc chắn chúng ta sẽ thấy graphql có nhiều điểm tương đồng với các api rest hiện nay, vậy nó có ưu điểm gì nổi bật? Tiếp theo chúng ta so sánh.
So sánh với phần còn lại
Điểm cuối:
Sử dụng api còn lại, bạn sẽ sử dụng nhiều điểm cuối để tìm nạp dữ liệu.
Điểm cuối
Giải quyết vấn đề tìm nạp quá mức và tìm nạp thiếu (quá tải và thiếu tải):
Nghỉ:
tìm nạp quá mức: ứng dụng khách chỉ cần lấy tên của người dùng, nhưng với api còn lại, bạn gọi điểm cuối /users và nhận một mảng json dữ liệu người dùng (có thể bao gồm cả ngày sinh nhật). email, địa chỉ,…)
tìm nạp thiếu: Một điểm cuối cụ thể không cung cấp đủ thông tin được yêu cầu cho khách hàng. Máy khách phải thực hiện thêm yêu cầu để lấy thêm dữ liệu (lấy danh sách các phần tử, mỗi phần tử cần thực hiện một yêu cầu để lấy dữ liệu được yêu cầu).
đồ thị:
Cơ sở dữ liệu càng lớn, bạn càng thấy được tính linh hoạt và lợi thế của graphql.
Phản ứng nhanh chóng với các thay đổi của khách hàng.
api còn lại:
đồ thị:
Phân tích dư thừa dữ liệu.
api còn lại:
đồ thị:
Một số nhược điểm của graphql:
Độ phức tạp:
Các vấn đề về bộ nhớ đệm:
api còn lại:
đồ thị:
Dự án demo graphql đơn giản với spring boot và mariadb:
1. Tạo dự án springboot, sử dụng maven:
2. Kết nối cơ sở dữ liệu:
3. Tạo mô hình:
4. Sử dụng tệp .graphql để thiết kế lược đồ cần thiết
5. Dịch vụ lớp học:
6. Trình phân tích cú pháp tương ứng:
Xem thêm:
