forzamilan
Posts: 2
Joined: Sun Nov 01, 2020 11:39 am

GraphQL sẽ cung cấp sức mạnh cho web phi tập trung

Fri Nov 20, 2020 1:06 pm

Truy vấn dữ liệu phi tập trung

Nếu blockchains là một kiểu cơ sở dữ liệu mới nguyên thủy, thì chúng ta sẽ truy vấn dữ liệu đó như thế nào? Nó sẽ thông qua các API RESTful, lệnh gọi RPC, giao diện SQL? Câu trả lời chắc chắn sẽ là tất cả những điều trên, nhưng đối với các ứng dụng phi tập trung nhằm mục đích cung cấp hiệu suất cấp người tiêu dùng được xây dựng trên blockchain, GraphQL là sự lựa chọn tối ưu.

GraphQL hiệu quả hơn các API REST hoặc RPC

GraphQL vừa là ngôn ngữ truy vấn vừa là ngôn ngữ định nghĩa giao diện (IDL) và được phát minh và có nguồn mở bởi Facebook. Nó được thiết kế để khắc phục sự cứng nhắc và kém hiệu quả của các API RESTful truyền thống, mà chúng tôi đã thảo luận trước. Nó thực hiện điều này bằng cách đưa ra một ngôn ngữ truy vấn mạnh mẽ, nhưng tiện dụng, trực tiếp cho người tiêu dùng API.
Với các API REST (Truyền trạng thái đại diện) truyền thống, mỗi thực thể hoặc tài nguyên có một điểm cuối riêng biệt xác định dữ liệu bạn sẽ nhận được về thực thể đó. Ví dụ: để nhận được tên của tổ chức mà người dùng thuộc về, trước tiên bạn có thể phải thực hiện cuộc gọi đến:

/api/v2/users/1

Và sau đó là một cuộc gọi tới:

/api/v2/organizations/7

Một ứng dụng trong thế giới thực được xây dựng trên các API truyền thống có thể thực hiện hàng chục hoặc hàng trăm cuộc gọi mạng khứ hồi. Và, đây không chỉ là vấn đề đối với REST. AdChain, một ứng dụng phi tập trung phổ biến, được xây dựng dựa trên Ethereum RPC API và buộc phải thực hiện hàng trăm cuộc gọi mạng khứ hồi tới Infura để tải giao diện người dùng của nó, dẫn đến mạng bị tắc nghẽn và thời gian tải không tối ưu.


Hàng trăm cuộc gọi mạng đến Infura được thực hiện bởi cơ quan đăng ký AdChain, tính đến thời điểm viết bài này

Mặt khác, GraphQL đủ mạnh để thể hiện tất cả dữ liệu mà ứng dụng yêu cầu trong một truy vấn duy nhất. Bất kể bạn cần bao nhiêu dữ liệu, với GraphQL, bạn không bao giờ cần thực hiện nhiều cuộc gọi mạng. Điều này đôi khi được gọi là giải quyết vấn đề tìm nạp dưới mức. Hơn nữa, bạn chỉ nhận được chính xác dữ liệu bạn yêu cầu và hết, do đó giải quyết vấn đề tìm nạp quá mức.

Kết quả là các giao diện, ít quan tâm hơn đến cách chúng được sử dụng, chỉ cung cấp cho bạn dữ liệu bạn muốn và không yêu cầu cập nhật liên tục để hỗ trợ các trường hợp sử dụng mới của các nhà phát triển bên ngoài.

GraphQL tốt hơn SQL cho các ứng dụng phi tập trung

Nhưng tại sao không sử dụng một ngôn ngữ truy vấn khác, chẳng hạn như SQL, để truy vấn các blockchains dữ liệu như một số người đã yêu cầu?


Nói rõ hơn, tôi nghĩ điều này có thể và nên xảy ra. SQL đã được chấp nhận rộng rãi trên toàn thế giới, quen thuộc với hàng triệu nhà phát triển và hoàn toàn mạnh hơn GraphQL như một ngôn ngữ truy vấn. Nó đặc biệt quen thuộc với các nhà khoa học dữ liệu và kỹ sư dữ liệu, những người có thể không quen với GraphQL. Tuy nhiên, SQL sẽ không phải là ngôn ngữ được ưa thích bởi các ứng dụng phi tập trung (dApps) xây dựng trên blockchain.

Có một vài lý do chính khiến GraphQL sẽ chiến thắng SQL đối với các dApp được xây dựng trên blockchain:
1. GraphQL là “đủ mạnh”
2. GraphQL tiện dụng hơn cho các nhà phát triển front-end
3. GraphQL được thiết kế để sử dụng trên các ranh giới tin cậy của tổ chức

Hãy đi sâu vào.

1. GraphQL “đủ mạnh”

Mặc dù ngôn ngữ truy vấn GraphQL không thực sự diễn đạt như SQL, nhưng điểm cuối GraphQL được thiết kế tốt có thể được thiết kế để cung cấp cho bạn hầu hết các khả năng truy vấn mà bạn mong đợi từ giao diện truy vấn SQL. Ví dụ: thông số GraphQL tự nhiên không chỉ định cách thực hiện tổng hợp, nhưng các tiêu chuẩn như OpenCRUD đã xuất hiện chỉ định cách hiển thị chức năng này.

Vẫn còn một số chức năng đuôi dài, chẳng hạn như kết hợp đặc biệt giữa các thực thể, có thể sẽ luôn nằm ngoài khả năng của API GraphQL. Tuy nhiên, tôi ước tính rằng đối với 99,9% các trường hợp sử dụng cần thiết cho các ứng dụng giao diện người dùng, GraphQL là đủ tốt.

2. GraphQL tiện dụng hơn cho các nhà phát triển front-end

Đối với những gì bạn từ bỏ quyền lực bằng cách chọn GraphQL, bạn sẽ trở lại công thái học. Ví dụ: GraphQL có cú pháp giống JSON quen thuộc:

query {
user (id:1) {
name
organization {
name
}
}
}

Và, phản hồi của truy vấn GraphQL là một đối tượng JSON phản ánh chính xác hình dạng của yêu cầu.

{
"user": {
"name": "Vitalik",
"organization": {
"name": "Ethereum Foundation"
}
}

Do JSON là định dạng dữ liệu được sử dụng phổ biến nhất để truyền dữ liệu trên web, nên cú pháp này cực kỳ dễ tiếp cận đối với hầu hết các nhà phát triển web.

Trong khi đó, truy vấn SQL tương đương sẽ giống như sau:

SELECT user. name, organization. name
FROM user JOIN organization ON (user.organization_id=organization. id)
WHERE user. id=1

Không phải là điều tồi tệ nhất để xem xét, nhưng nó được cho là kém đơn giản hơn so với truy vấn GraphQL.

Và, dữ liệu phản hồi sẽ không được chuẩn hóa và sẽ ở dạng bảng, được gửi trong giao thức dây độc quyền của cơ sở dữ liệu SQL cụ thể mà bạn đang sử dụng. Điều này trái ngược với cách lồng trực quan của phản hồi GraphQL, được thể hiện dưới dạng JSON văn bản thuần túy được gửi qua HTTP.

Hệ sinh thái GraphQL, cũng có công cụ, chẳng hạn như React-Apollo, giúp tích hợp dữ liệu được tìm nạp qua GraphQL trực tiếp vào các thành phần giao diện người dùng của các ứng dụng web vô cùng đơn giản. Vì SQL hầu như không bao giờ được sử dụng qua HTTP trực tiếp từ các ứng dụng web hoặc di động, không có công cụ nào như vậy tồn tại trong hệ sinh thái SQL mà tôi biết.

3. GraphQL được thiết kế để sử dụng qua các ranh giới tin cậy

Có lẽ quan trọng hơn, các điểm cuối SQL không bao giờ được thiết kế để sử dụng qua ranh giới tin cậy của tổ chức. Ví dụ: nếu chúng tôi đang sử dụng SQL để cung cấp dữ liệu blockchain chỉ đọc, thì một truy vấn SQL quá phức tạp cũng đủ để đưa cơ sở dữ liệu của bạn vào trạng thái thu thập thông tin, khiến cho bất kỳ ai khác cũng không thể sử dụng được.

GraphQL cũng đủ mạnh để kích hoạt các tính toán tốn kém tùy ý trên phần phụ trợ của bạn, tuy nhiên, không giống như SQL, giải quyết vấn đề này đã là một lĩnh vực trọng tâm ngay từ ngày đầu tiên và ngày càng có nhiều nghiên cứu và công cụ để cho phép tự động chặn các truy vấn đắt tiền và điều chỉnh khách hàng.

Trong khi đó, cách tiếp cận tương tự để giải quyết vấn đề này trong SQL theo truyền thống là tìm các truy vấn chậm theo cách thủ công và chỉ cần viết lại chúng. Ngoài ra, người ta có thể thêm chỉ mục hoặc thay đổi lược đồ cơ sở dữ liệu để giảm bớt tác động của các truy vấn đắt tiền “được chấp thuận”. Đó là bản chất của cách SQL luôn được triển khai trong các tổ chức, với chỉ một nhóm người hoặc dịch vụ được kiểm soát chặt chẽ mới có thể truy vấn trực tiếp điểm cuối.


Một nơi khác mà DNA đa tổ chức của GraphQL tỏa sáng là trong phần nội quan của lược đồ. GraphQL coi việc xem xét lược đồ là mối quan tâm hàng đầu của ngôn ngữ.

Ví dụ: loại Gốc trong GraphQL có trường __schema có thể được sử dụng để xem xét các loại có sẵn để truy vấn:


Nói một cách công bằng đối với SQL, mặc dù một số truy vấn nội quan có thể trông thực sự khủng khiếp, nhưng một phần nội quan chủ yếu tương tự như ở trên trông không khủng khiếp nếu bạn đã quen thuộc với cú pháp:

SELECT c.table_schema, c.table_name,c.column_name,pgd.description
FROM pg_catalog.pg_description pgd
RIGHT JOIN information_schema.column c on
(pgd.objsubid=c.ordinal_position)
WHERE c.table_schema NOT IN ('pg_catalog', 'information_schema');


Tuy nhiên, truy vấn SQL này có đầy đủ các tham số dành riêng cho nhà cung cấp cho cơ sở dữ liệu Postgres. Truy vấn tương đương cho cơ sở dữ liệu MySQL sẽ khác. Ngoài ra, mặc dù truy vấn trên đủ dễ để đọc dưới dạng văn bản thuần túy, nhưng việc gửi truy vấn đó và nhận phản hồi, yêu cầu công cụ đặc biệt — một ứng dụng khách CLI dành riêng cho nhà cung cấp hoặc một GUI cho máy tính để bàn của nhiều nhà cung cấp, hiểu được hương vị SQL dành riêng cho nhà cung cấp, giao thức dây, ODBC hoặc một số kết hợp của những điều trên.
Mặt khác, GraphQL trả về JSON văn bản thuần túy qua HTTP cho tất cả các truy vấn, bao gồm cả các truy vấn xem xét nội dung, để bạn có thể bắt đầu từ điểm cuối với Postman, Công cụ Chrome Dev hoặc lệnh curl đơn giản được tải trước trên mọi máy Mac và Thiết bị đầu cuối hệ điều hành Linux.

Phần kết luận

Đúng là nhiều thiếu sót của REST và SQL mà tôi đã đánh dấu không phải là không có cách khắc phục. Đã có những nỗ lực để giải quyết các vấn đề tìm nạp quá mức và tìm nạp dưới mức với các API RESTful. Đã có những nỗ lực để thêm các lược đồ vào các API RESTful, về mặt lý thuyết có thể được phân phát từ một điểm cuối được xác định trước. SQL cũng chỉ là một ngôn ngữ truy vấn, không phải là một triển khai, và do đó, không có gì ngăn chúng ta xây dựng một giao diện SQL sử dụng HTTP, trả về CSV hoặc JSON văn bản thuần túy qua dây và có nhiều khả năng xem xét nội tâm hợp lý hơn. Tuy nhiên, việc truy vấn trực tiếp dữ liệu tùy ý một cách hiệu quả, qua các ranh giới tin cậy của tổ chức khi các mạng lưu trữ theo địa chỉ nội dung và blockchain hiện đã được kích hoạt, đơn giản không nằm trong DNA của một trong hai công nghệ này.

GraphQL, trong khi đó, được thiết kế từ đầu cho trường hợp sử dụng này. Nó được thiết kế với sự chú ý của các kỹ sư front-end với GUI thân thiện với người dùng để xem xét nội quan nâng cao và công cụ hoàn thiện giúp việc liên kết các truy vấn GraphQL với các thành phần UI trong trình duyệt gần như liền mạch. Trong một mô hình mà các dApp chủ yếu bao gồm các ứng dụng trình duyệt giao tiếp với các hợp đồng thông minh chạy trên blockchain, nhu cầu và sở thích của các kỹ sư front-end sẽ là động lực để xác định nền tảng công nghệ của web phi tập trung. Đó là lý do tại sao chúng tôi đã thấy nhiều nỗ lực để đặt giao diện GraphQL trước API JSON RPC của Ethereum.

Tại The Graph, chúng tôi tin rằng việc xây dựng trải nghiệm người dùng phong phú với hiệu suất ở cấp độ người tiêu dùng, trên các blockchain, là một trong những rào cản chính để đạt được sự áp dụng rộng rãi của blockchain và web phi tập trung. Đó là lý do tại sao tháng 7 năm ngoái, chúng tôi mở nguồn máy chủ lập chỉ mục cho phép các nhà phát triển truy vấn hiệu quả dữ liệu Ethereum và IPFS cho các ứng dụng phi tập trung của họ thông qua giao diện GraphQL. Trong tương lai, khi các đường ống phân tích cho khoa học dữ liệu và học máy trên blockchain trở thành một trường hợp sử dụng phổ biến hơn, chúng ta sẽ xem xét việc hỗ trợ SQL và có lẽ cả các ngôn ngữ truy vấn khác… Ví dụ như Datalog.

Nếu bạn đang xây dựng một thứ gì đó thú vị trên blockchain, tôi rất muốn nghe về nó và cách bạn tìm nạp dữ liệu, trong các nhận xét. Cảm ơn vì đã đọc!

Discord: justacryptonoob#0840

Return to “Tiếng Việt (Vietnamese)”

Who is online

Users browsing this forum: No registered users and 9 guests