GraphQL станет основой децентрализованного Интернета
Использование блокчейнов и сетей хранения в качестве уровня взаимодействия данных
Перевод статьи Брэндона Рамиреса.
На протяжении десятилетий единственной широко используемой базой данных была база данных SQL, и она по-прежнему лежит в основе большинства организаций, программных приложений и учреждений. Однако с появлением блокчейна наконец-то появилась альтернатива реляционной базе данных, и я говорю не только о постепенных улучшениях, вызванных движением NoSQL. Мы находимся на пороге новой парадигмы, получившей название децентрализованной сети или Web3, где данные, а не проприетарные APIs, являются фундаментальной основой для взаимодействия. В этом посте я объясню, почему происходит этот переход, и как язык запросов GraphQL займет уникальное положение для обеспечения этой новой эры взаимодействия данных.
Проблема проприетарных APIs
Интернет сегодня связан через проприетарные интерфейсы прикладного программирования (API), которые существуют в основном для устранения ограничений централизованной, обычно SQL, базы данных. Описывая положение дел, Виней Гупта, ранее работавший в фонде Ethereum, заметил:
Когда у вас есть одна большая база данных в центре вашей организации, которая хранит всю правду и всю мудрость, вы очень неохотно позволяете другим людям прикасаться к этой базе данных.
Таким образом, проприетарные APIs, работающие на серверах, действуют как защитный барьер для центральной базы данных. Они ограничивают то, что входит, что выходит, кем и в каком формате. С помощью шаблона микросервисов мы даже инкапсулируем данные внутри организаций, так что сервисы, созданные разными командами, должны проходить через API друг друга. Несмотря на то, что это привело нас туда, где мы находимся сегодня, такое распространение APIs имеет следующие недостатки:
- APIs негибкие и дорогостоящие в обслуживании.
- Текущая модель неэффективна.
- Проприетарные APIs приводят к монополии данных.
Давайте рассмотрим каждый из них более подробно.
1. APIs являются сложными и дорогостоящими в обслуживании
APIs, в частности REST APIs (подробнее об этом позже), разрабатываются с учетом конкретных вариантов использования, таких как функция в веб-приложении, и чем дальше вы уходите от этих вариантов использования, тем сложнее их использовать.
В организациях это приводит к постоянно расширяющейся области API. Каждая новая функция требует дополнительных инженерных работ для расширения API с помощью новой конечной точки. Каждая новая конечная точка, в свою очередь, требует постоянных инженерных работ для обслуживания и поддержки в течение всего срока ее использования, что может занимать много времени.
Наряду с этим потребители общедоступных APIs вынуждены придерживаться тех вариантов использования, которые разработчики API решили поддерживать. Кайл Дейгл, директор по экосистемной инженерии Github, четко сформулировал проблему:
Практически каждый API управляет интеграцией как это было задумано… каждый API, который я могу придумать … у всех есть своего рода представление о том, как они хотят, чтобы вы его использовали, и если вы хотите это изменить, это в принципе невозможно … по сути, вам нужно создать свой собственный API на основе этого.
Негибкость этих публичных APIs требует тонны дополнительных инженерных усилий, чтобы обойти их, что подводит нас к следующему пункту.
2. Текущая модель неэффективна.
Как мы уже видели, негибкость APIs приводит к распространению большего количества баз данных и APIs, часто для хранения одних и тех же данных, просто в другом формате. Каждая из этих новых баз данных и API требует дополнительных инфраструктурных и инженерных ресурсов для обслуживания.
Это также приводит к невероятному количеству дополнительных действий. Опять же, цитируя Винея Гупту на эту тему:
Когда вы подаете форму в IRS, она проходит через 6 или 7 процессов, прежде чем попадет в их базы данных… все сотрудничество [является] непрямым, бюрократическим, трудным.
В своей статье, описывающей эту проблему в контексте исследовательских данных, Брендан О’Брайен и Майкл Хака описывают первенство базы данных SQL как паттерн “база данных в середине”, показанный ниже:
Любая достаточно несложная программная система будет включать в себя бесчисленные серверы, кодирующие данные из одной базы данных, обслуживающие их по сети, декодирующие данные, помещая их в другую базу данных и повторяя этот процесс много раз.
О’Брайен и Хака продолжают описывать, как обычно в этих конвейерах данных промежуточные результаты хранятся в частной базе данных или полностью выбрасываются из-за технических усилий, необходимых для того, чтобы сделать эти данные общедоступными. В результате возникают два измерения дублирования: внутри конвейеров данных и между конвейерами данных, создаваемыми изолированными командами и организациями.
3. Проприетарные APIs приводят к монополии данных
Необходимость хранить данные в хранилищах также ведет к риску недобросовестного поведения. Это стало обычным явлением на технологической сцене, когда крупный технологический гигант отзывает доступ к своим проприетарным APIs после того, как ранее поощрял разработчиков строить на своей платформе.
Facebook сделал это намеренно, чтобы задушить конкуренцию, а Twitter сделал это, чтобы более эффективно монетизировать свои данные. Главный автор InfoWorld, Сердар Йегулалп, осветил историю Twitter, кратко описав риски, связанные с использованием проприетарных APIs:
Назовите это одной из профессиональных опасностей экономики API: чем шире и многограннее зависимость от одного объекта — будь то источник данных, аналитический уровень или инфраструктура, — тем легче выдернуть ковер из-под ваших ног.
Парадигма архитектуры программного обеспечения, которая требует, чтобы данные оставались за привратниками, естественно, способствует пагубной практике этих монополий на данные.
Чтобы не быть слишком несправедливым, я должен отметить, что подключение на основе API было огромным успехом. APIs создали огромную экономическую ценность, позволив разработчикам создавать программное обеспечение из небольших специализированных сервисов, таких как Stripe или Twilio. Они дали нам возможность безопасно передавать данные между приложениями в устаревшем технологическом ландшафте, где доминирует SQL. Интернет, который мы знаем и любим сегодня, не был бы тем, чем он является без APIs. Но теперь, с появлением блокчейна и других технологий web3, у нас есть шанс вступить в новую эру взаимодействия без трений в интернете.
Блокчейн и контентно-адресуемое хранилище данных
В основе недостатков SQL, как и большинства баз данных NoSQL, лежит использование информационной модели, которая изменяет данные на месте. Рич Хики, создатель языка программирования Clojure и базы данных Datomic, называет это место-ориентированное программирование (PLOP), и хотя когда-то это было необходимо для преодоления ограничений небольшой памяти и размера диска, ему больше нет места в современной информационной модели. Когда данные могут быть изменены на месте произвольными способами, невозможно быть уверенным, что данные верны или не изменились у вас под ногами с момента последнего доступа к ним. Поэтому неудивительно, что обе технологии обеспечивающие децентрализованную сеть - блокчейн и контентно-адресуемое хранилище данных, подчеркивают неизменность своих информационных моделей.
Контентно-адресуемое хранилище данных
Хотя о блокчейнах гораздо больше шумихи, я начну с объяснения, что такое контентно-адресуемое хранилище данных, поскольку это более простая и фундаментальная концепция. Идея заключается в следующем: любая часть данных — объект в базе данных, файл в файловой системе, большой двоичный объект в CDN — как вы ссылаетесь на эти данные? Вы даете им произвольный идентификатор, URL-адрес или имя, которое может относиться к разным данным в разное время, в зависимости от того, как вы спрашиваете… или даете ему уникальный идентификатор, постоянный, который всегда имеет определенное значение, независимо от того, откуда он обслуживается — локально в вашей собственной файловой системе, на удаленном сервере или с другой планеты?
Контентно-адресуемые хранилища данных, такие как межпланетная файловая система (InterPlanetary File System) или распределенная система контроля версий Git, применяют последний подход, используя идентификаторы, которые однозначно вычисляются (с использованием хэш-функции) из самого содержимого. Поскольку идентификатор содержимого всегда должен возвращать одно и то же содержимое, которое, в свою очередь, может быть использовано для повторного вычисления идентификатора, проверка целостности данных является несложной задачей.
На этом этапе вы можете задать себе вопрос, если контентно-адресуемое хранилище данных является неизменяемым, то как мы можем сделать с ним что-нибудь полезное? В конце концов, вещи в реальном мире, которые мы используем, например— баланс вашего банковского счета, ваш список друзей, ваш список дел, — со временем меняются. Как мы можем представить концепции, которые меняются со временем, используя неизменяемые данные в качестве основного строительного блока? Здесь на помощь приходят блокчейны.
Блокчейны
Блокчейн, по своей сути, представляет собой структуру данных неизменяемых значений, в которой возможно только добавление —последовательная цепочка блоков, содержащих информацию. Хотя каждый блок является неизменяемым, мы можем имитировать изменчивость, при помощи переменных, таких как балансы счетов или состояние смарт-контрактов, которые различаются по значению от блока к блоку. Благодаря этому получаем свободную возможность проверки, то есть мы можем видеть, как любая переменная менялась с течением времени, что позволяет внешним процессам напрямую полагаться на эти данные.
Блокчейны с возможностями смарт-контрактов, такие как Ethereum, также дают нам способ прописать, как и кем могут быть изменены фрагменты данных, безопасным способом — ответственность, которая обычно входила в компетенцию централизованных интерфейсов прикладного программирования (APIs).
Оба эти нововведения открывают новую парадигму, в которой данные, хранящиеся в блокчейнах и контентно-адресуемых сетях, действуют как уровень взаимодействия:
Поскольку блокчейны спроектированы так, чтобы быть децентрализованными, не иметь разрешений и работать во враждебных средах, нет необходимости скрывать их за каким-либо дополнительным защитным слоем для обеспечения безопасности и надежности. Для данных, хранящихся в блокчейнах или контентно-адресуемых сетях, проприетарные APIs больше не являются архитектурной необходимостью — процессы могут напрямую взаимодействовать с децентрализованными данными в качестве общей основы для взаимодействия.
Запрос децентрализованных данных
Если блокчейны — это новый тип примитивов базы данных, то как мы будем запрашивать эти данные? Будет ли это через RESTful API, RPC, интерфейсы SQL? Ответом неизбежно будет все вышеперечисленное, но для децентрализованных приложений, которые стремятся обеспечить производительность потребительского уровня, построенную на блокчейне, GraphQL является естественным выбором.
GraphQL более эффективен, чем REST или RPC APIs.
GraphQL — это одновременно язык запросов и язык описания интерфейсов (interface definition language (IDL)), который был изобретен Facebook и имеет открытый исходный код. Он был разработан для преодоления негибкости и неэффективности традиционных RESTful API, о которых мы ранее говорили в этом посте. Он делает это, предоставляя мощный, удобный язык запросов непосредственно потребителям API.
В традиционных API REST (передача состояния представления) каждый объект или ресурс имеет отдельную конечную точку, которая определяет данные, которые вы получите об этом объекте. Например, чтобы узнать название организации, к которой принадлежит пользователь, вам может потребоваться сначала запросить:
/api/v2/users/1
затем запросить:
/api/v2/organizations/7
В реальных условиях применения, приложение, построенное на традиционных APIs, может выполнять десятки или сотни сетевых запросов туда и обратно. И это проблема не только для REST. AdChain, популярное децентрализованное приложение, основано на Ethereum RPC API и вынуждено делать сотни сетевых запросов Infura туда и обратно для загрузки своего пользовательского интерфейса, что приводит к перегрузке сети и неоптимальному времени загрузки.
С другой стороны у нас GraphQL, достаточно мощный, чтобы передать все данные, необходимые приложению, в одном запросе. Независимо от того, сколько данных вам нужно, с GraphQL вам никогда не потребуется выполнять более одного сетевого запроса. Иногда это называют решением проблемы недостаточной выборки. Кроме того, вы получаете только те данные, которые запрашивали, и не более того, что решает проблему избыточной выборки.
Результатом являются интерфейсы, которые гораздо менее категоричны в отношении того, как они используются, предоставляют вам только те данные, которые вам нужны, и не требуют постоянного обновления для поддержки новых вариантов использования внешними разработчиками.
GraphQL лучше SQL для децентрализованных приложений
Некоторые спросят: почему для запроса данных блокчейнов, не использовать другой язык запросов, такой как SQL?
Чтобы внести ясность, я думаю, что это может и должно произойти. SQL получил широкое распространение во всем мире, он знаком миллионам разработчиков и является более мощным языком запросов, чем GraphQL. Он особенно хорошо знаком специалистам по данным, которые могут быть незнакомы с GraphQL. Тем не менее, SQL не будет предпочтительным языком для децентрализованных приложений (dApps), построенных на блокчейне.
Есть несколько основных причин, по которым GraphQL победит SQL если делать выбор для приложений, построенных на блокчейне:
- GraphQL- “достаточно мощный”
- GraphQL более удобный для front-end разработчиков
- GraphQL был разработан, для использования, невзирая на организационные границы доверия
Давайте погрузимся.
1. GraphQL «достаточно мощный»
Несмотря на то, что язык запросов GraphQL изначально не так выразителен, как SQL, хорошо спроектированная конечная точка GraphQL может быть сконструирована так, чтобы предоставить вам большинство возможностей запроса, которые вы ожидаете от интерфейса SQL. Например, спецификация GraphQL изначально не устанавливает способ выполнения агрегирования, но появились стандарты, такие как OpenCRUD, которые указывают, как предоставлять эту функциональность.
Все еще существуют некоторые “long-tail” функции , такие как ad-hoc соединения, которые, скорее всего, всегда будут недоступны для API GraphQL. Однако я считаю, что для 99,9% случаев использования, необходимых для интерфейсных приложений, GraphQL достаточно хорош.
2. GraphQL более удобный для front-end разработчиков
Вы получаете удобство, за то немногое, что вы теряете отказываясь от SQL и выбирая GraphQL. Например, GraphQL имеет знакомый JSON-подобный синтаксис:
Кроме того, ответ на запрос GraphQL-это JSONobject, который точно отражает форму запроса.
Учитывая, что JSON является наиболее часто используемым форматом данных для передачи данных в интернете, этот синтаксис невероятно доступен для большинства веб-разработчиков.
Между тем эквивалентный SQL-запрос будет выглядеть так:
Не самая плохая вещь, на которую можно посмотреть, но, возможно, он менее прост, чем запрос GraphQL.
И данные ответа будут необычны и представлены в виде таблиц, отправленных по проприетарному wire протоколу конкретной базы данных SQL, которую вы используете. Это контрастирует с интуитивно понятным содержимым ответа GraphQL, выраженного в виде простого текста JSON, отправленного по HTTP.
Экосистема GraphQL также имеет инструменты, такие как React-Apollo, что делает невероятно простой интеграцию данных, полученных с помощью GraphQL, непосредственно в компоненты пользовательского интерфейса веб-приложений. Насколько мне известно, в экосистеме SQL, таких инструментов не существует, поскольку SQL почти никогда не используется через HTTP непосредственно из мобильных или веб-приложений.
3. GraphQL был разработан, для использования, невзирая на организационные границы доверия
Возможно, что еще более важно, конечные точки SQL никогда не были предназначены для использования через границы доверия организации. Например, если мы используем SQL для предоставления блокчейн-данных только для чтения, то слишком сложного SQL-запроса будет достаточно, чтобы ваша база данных была сканирована, что делает ее непригодной для использования кем-либо еще.
GraphQL также достаточно мощен, чтобы запускать дорогостоящие вычисления на вашем бэкэнде, однако, в отличие от SQL, решение этой проблемы было в центре внимания с самого начала, и существует растущий объем исследований и инструментов, позволяющих динамически блокировать дорогостоящие запросы и контролировать клиентов.
Между тем, аналогичный подход к решению этой проблемы в SQL традиционно заключается в том, чтобы вручную находить медленные запросы и просто перезаписывать их. Кроме того, можно добавить индексы или изменить схему базы данных, чтобы уменьшить влияние “одобренных” дорогостоящих запросов. Такова природа того, как SQL всегда развертывался в организациях, когда только строго контролируемая группа людей или служб могла напрямую запрашивать конечную точку.
Еще одна отличительная черта межорганизационной ДНК GraphQL — это самоанализ схемы. GraphQL рассматривает самоанализ схемы как первоочередную задачу языка.
Например, тип Root в GraphQL имеет поле __schema , которое можно использовать для анализа типов, доступных для запроса:
Честно говоря, хотя некоторые запросы самоанализа могут выглядеть поистине ужасающими, если вы знакомы с синтаксисом они уже не будут казаться такими ужасными.
Однако этот SQL-запрос полон параметров, зависящих от поставщика для базы данных Postgres. Эквивалентный запрос для базы данных MySQL будет другим. Кроме того, хотя приведенный выше запрос достаточно легко читать как обычный текст, отправка этого запроса и получение ответа требует специального инструментария — клиента CLI для конкретного поставщика или графического интерфейса рабочего стола между поставщиками, который понимает разновидности SQL, зависящие от поставщика, wire протоколы, ODBC или комбинация вышеперечисленного.
C другой стороны у нас GraphQL, который возвращает простой текст JSON через HTTP для всех запросов, включая запросы самоанализа, так что вы можете проверить это, чтобы убедиться, на конечной точке с помощью Postman, Chrome Dev Tools или простой команды curl, которая предварительно загружена на каждый Mac и Терминал ОС Linux.
Вывод
Это правда, что многие недостатки REST и SQL, которые я указал, не остаются без внимания. Предпринимались попытки решить проблемы с избыточной и недостаточной выборкой с помощью RESTful APIs. Были предприняты попытки добавить схемы в RESTful APIs, которые теоретически могут обслуживаться из предопределенной конечной точки. SQL также является просто языком запросов, а не реализацией, и поэтому ничто не мешает нам создать интерфейс SQL, который использует HTTP, возвращает простой текст CSV или JSON по сети и имеет более разумные возможности самоанализа. Однако эффективный запрос произвольных данных напрямую, через организационные границы доверия, как это теперь сделали возможным блокчейн и контентно-адресуемое хранилище данных, просто не входит в ДНК ни одной из этих двух технологий.
Между тем GraphQL был разработан с нуля для этого варианта использования. Он был создан с расчетом на front-end инженеров с удобными графическими интерфейсами для расширенного самоанализа и готовыми инструментами, которые позволяют практически без проблем привязывать запросы GraphQL к компонентам пользовательского интерфейса в браузере. В парадигме, где dApps в основном состоят из приложений браузера, взаимодействующих со смарт-контрактами, работающими на блокчейне, потребности и предпочтения front-end инженеров будут движущей силой в определении технологического стека децентрализованной сети. Вот почему мы уже видим многочисленные попытки поставить интерфейс GraphQL перед JSON RPC API Ethereum.
В The Graph мы считаем, что создание богатого пользовательского опыта с производительностью потребительского уровня, помимо блокчейнов, является одним из основных препятствий на пути к широкому распространению блокчейна и децентрализованной сети. Вот почему в июле прошлого года мы открыли исходный код сервера индексации, который позволяет разработчикам эффективно запрашивать данные Ethereum и IPFS для своих децентрализованных приложений через интерфейс GraphQL. В будущем, когда конвейеры аналитики для науки о данных и машинного обучения на блокчейне станут более распространенным вариантом использования, мы рассмотрим поддержку SQL и, возможно, других языков запросов … Datalog, кто-нибудь?
Если вы создаете что-то классное на блокчейне, я бы хотел услышать об этом и о том, как вы получаете данные, в комментариях. Спасибо за прочтение!
