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

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

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

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

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, устанавливает GraphQL API, которую можно использовать для запроса и манипуляции данными (чтения, обновления, добавления).

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

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

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

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