Graphql – Thay Đổi và Cải Thiện Cách Các Ứng Dụng Truyền Thông

Sẽ không còn lâu trước khi thế hệ tiếp theo sẽ mua tiền điện tử và kiểm tra số dư tín thác của họ trong phòng chờ Fortnite giữa các trò chơi. Điều này sẽ được kích hoạt thông qua nhiều tiến bộ công nghệ.

Điều chúng ta đang thảo luận hôm nay là cách dữ liệu được truyền tải (đọc, cập nhật, thêm/xóa) giữa các ứng dụng và các công ty sở hữu chúng. Các giao diện lập trình ứng dụng (API) là kiến trúc định nghĩa giao tiếp dữ liệu này và khi các tiêu chuẩn này phát triển, các yêu cầu xử lý và lưu trữ dữ liệu đã trở nên ít nặng nề hơn.

Người dẫn đầu trong gói về “sử dụng tài nguyên nhẹ” là GraphQL, một ngôn ngữ truy vấn và xử lý dữ liệu mã nguồn mở. Cơ sở của hệ sinh thái của nó là đặc tả và một bộ công cụ đã được tạo ra xung quanh nó.

Nó không mới – thời gian di chuyển nhanh. Facebook đã phát triển nó vào năm 2012 và chỉ sử dụng nó nội bộ cho phát triển ứng dụng di động. Vào năm 2015, nó đã được “mã nguồn mở” và ngày nay nó được chăm sóc bởi Quỹ GraphQL (https://graphql.org/foundation/) giám sát sự phát triển thêm của nó.

Vậy tại sao tôi lại viết về nó bây giờ? Một con đường điển hình đến việc áp dụng công nghệ sẽ theo các giai đoạn sau: 1) những người đam mê/sản phẩm cá nhân, 2) thực hiện trên nhiều ngôn ngữ, 3) thực hiện trên các công ty khởi nghiệp và nhỏ, 4) các công ty vừa và được sử dụng trong phát triển sản phẩm, 5) các tập đoàn lớn và gã khổng lồ công nghệ.

GraphQL đã đạt đến cấp độ 5. Hiện tại, nó được sử dụng bởi GitHub, Pinterest, Shopify, Microsoft để đặt tên và gần đây nhất, từ tháng 3 năm 2022, Salesforce.

Khi tìm kiếm cách để lấy dữ liệu một cách hiệu quả từ Salesforce, tôi đã tìm thấy tài liệu GraphQL của họ và bắt đầu đọc và tìm cách thực hiện nó.

GraphQL khác với API REST truyền thống như thế nào?

• Một trong những lợi thế chính là với GraphQL, bạn có thể truy vấn và chỉ nhận lại dữ liệu cụ thể. Nếu bạn chỉ muốn hai trường liên quan đến một vụ việc khách hàng cụ thể, thì đó là những gì bạn nhận được. Một API REST truyền thống sẽ trả lại cho bạn TẤT CẢ các trường liên quan đến vụ việc. Đó có thể là 100+ trường. Bây giờ bạn phải làm điều gì đó với tất cả dữ liệu mà bạn không muốn từ đầu. Điều này được gọi là lấy quá nhiều dữ liệu (lấy quá ít dữ liệu cũng là một vấn đề).
• Điều trên làm cho GraphQL nhanh hơn so với các phương pháp API khác khi trả lại dữ liệu.
• GraphQL là một ngôn ngữ mạnh mẽ, điều này có nghĩa là các lỗi mã được phát hiện trước khi chương trình chạy và không trong khi nó đang chạy.
• Một bộ công cụ tuyệt vời đã được xây dựng xung quanh GraphQL, điều này đã làm cho nó rất thân thiện với nhà phát triển.
• GraphQL có một điểm cuối duy nhất so với API REST, có nhiều điểm cuối. Điều này có nghĩa là tất cả dữ liệu của bạn có thể được lấy trong một yêu cầu duy nhất.

Hai mặt của đồng tiền: người yêu cầu (khách hàng) và nhà cung cấp (trình chủ GraphQL)

Tôi đã xem xét GraphQL cho đến nay từ góc độ “yêu cầu” dữ liệu. Trong đó, một công ty như Salesforce hoặc Microsoft đã thiết lập một API GraphQL mà bạn có thể sử dụng để truy vấn và xử lý dữ liệu (đọc, cập nhật, thêm).

Ví dụ, nếu chúng tôi muốn bao gồm dữ liệu từ Salesforce liên quan đến các vụ việc khách hàng vào một cổng thông tin khách hàng, cách hiệu quả nhất để làm điều này sẽ là yêu cầu chính xác dữ liệu mà chúng tôi đang tìm kiếm thông qua một truy vấn GraphQL từ cổng thông tin đến máy chủ GraphQL của Salesforce. Bạn sẽ nhận được chính xác dữ liệu mà bạn muốn, không lấy quá nhiều hoặc quá ít và kết quả là không cần xử lý hoặc lưu trữ dữ liệu thêm.

Mặt khác của đồng tiền là tổ chức thiết lập kiến trúc GraphQL để khách hàng của họ có thể truy cập dữ liệu họ muốn một cách hiệu quả.

Khi xây dựng API GraphQL, một tổ chức đang tạo ra một mô hình tích hợp tất cả các hệ thống của họ vào một mô hình. Nó thống nhất các hệ thống này và một khi công việc được hoàn thành, việc truy vấn dữ liệu trở nên liền mạch thông qua API.

Khi so sánh các ứng dụng hoặc nhà cung cấp, tôi xem xét các chức năng họ cung cấp cho tôi để lấy lại dữ liệu của tôi từ họ. Tôi không muốn phải gửi email cho họ hoặc dựa vào các báo cáo định nghĩa cứng nhắc. Tôi muốn có thể “cắm vào” dữ liệu của mình và truy vấn nó một cách linh hoạt, kịp thời. Nếu nó giảm xuống hai ứng dụng/nhà cung cấp và chúng được khớp tương tự trên các điểm so sánh khác, và một trong số chúng cung cấp API REST hoặc API GraphQL, tôi chắc chắn sẽ chọn cái có API.