GraphQL – Изменение и улучшение способа общения между приложениями

Не пройдёт много времени, прежде чем следующее поколение будет покупать криптовалюту и проверять баланс своего доверительного фонда в Fortnite lobby между играми. Это будет возможно благодаря многим технологическим достижениям.

Одним из них является способ передачи данных (чтения, обновления, добавления/удаления) между приложениями и компаниями, которые их владеют. Архитектура интерфейсов программирования приложений (API) определяет эту коммуникацию данных, и по мере развития этих стандартов требования к обработке и хранению данных стали менее трудоёмкими.

Лидером в этом плане по “легкому” использованию ресурсов является GraphQL, открытый язык запроса и манипуляции данными. Основой его экосистемы является спецификация и набор инструментов, созданных вокруг него.

Он не новый – время идёт быстро. Facebook разработал его в 2012 году и использовал только внутренне для разработки мобильных приложений. В 2015 году он был “открыт” и сейчас он поддерживается фондом GraphQL (https://graphql.org/foundation/), который контролирует его дальнейшее развитие.

Итак, почему я пишу о нём сейчас? Типичный путь к технологической адопции будет включать следующие этапы: 1) хобби/личные проекты, 2) реализация на нескольких языках, 3) реализация в стартапах и небольших компаниях, 4) средние компании и использование в разработке продукта, 5) крупные корпорации и технологические гиганты.

GraphQL достиг уровня 5. В настоящее время он используется GitHub, Pinterest, Shopify, Microsoft, чтобы назвать лишь несколько, и, недавно, с марта 2022 года, Salesforce.

В поисках способа более эффективно получать данные из Salesforce, я наткнулся на их документацию GraphQL и начал читать и изучать способы его реализации.

Как он отличается от традиционного REST API?

• Одним из основных преимуществ является то, что с GraphQL вы можете запросить и получить только те данные, которые вам нужны. Если вам нужны только два поля, связанных с конкретным инцидентом клиента, то это именно то, что вы получите. Традиционный REST API вернёт вам ВСЕ поля, связанные с инцидентом. Это может быть 100+ полей. Теперь вам приходится что-то делать со всеми этими данными, которые вы не хотели изначально. Это называется избыточной загрузкой данных (недостаточная загрузка данных также является проблемой).
• Вышеуказанное делает GraphQL быстрее, чем другие методологии API при возврате данных.
• GraphQL – это сильно типизированный язык, который, среди прочего, означает, что ошибки кода обнаруживаются до запуска программы, а не во время её выполнения.
• Была создана отличная коллекция инструментов вокруг GraphQL, что сделало его очень удобным для разработчиков.
• GraphQL имеет одну конечную точку, в отличие от REST API, который имеет несколько конечных точек. Это означает, что все ваши данные можно получить в одном запросе.

Две стороны одной медали: запроситель (клиент) и поставщик (хост GraphQL)

Я рассмотрел GraphQL до сих пор с точки зрения запроса данных. Где компания, такая как Salesforce или Microsoft, настроила API GraphQL, который можно использовать для запроса и манипуляции данными (чтения, обновления, добавления).

Как пример, если мы хотим включить данные из Salesforce, связанные с инцидентами клиентов, в портал клиента, наиболее эффективным способом будет запросить точные данные, которые нам нужны, через запрос GraphQL из портала на сервер Salesforce GraphQL. Вы получите именно те данные, которые вам нужны, без избыточной или недостаточной загрузки, и в результате не потребуется дополнительная обработка или хранение данных.

Другая сторона медали – это организация, которая настраивает архитектуру GraphQL, чтобы клиентам был предоставлен эффективный метод доступа к желаемым данным.

При создании API GraphQL организация создаёт модель, которая интегрирует все системы в одну модель. Она унифицирует эти системы, и после завершения работы запрос данных становится бесшовным через API.

При сравнении приложений или поставщиков я смотрю на то, какие функции они предлагают мне, чтобы получить мои данные обратно от них. Я не хочу быть вынужденным отправлять им электронные письма или полагаться на жесткие предварительно определённые отчёты. Я хочу иметь возможность “подключиться” к моим данным, запросив их гибким и своевременным образом. Если это сводится к двум приложениям/поставщикам, и они сопоставимы по другим сравнительным пунктам, и один предлагает либо REST API, либо GraphQL API, я, безусловно, выберу тот, у которого есть API.