Graphql — изменение и улучшение способа взаимодействия приложений

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

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

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

Это не ново — время движется быстро. Facebook разработал его в 2012 году и использовал только внутри компании для разработки мобильных приложений. В 2015 году он был «с открытым исходным кодом», и сегодня за ним следит GraphQL Foundation (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 с портала на сервер Salesforce GraphQL. Вы получите именно те данные, которые вам нужны, без недобора или избыточной выборки, и в результате не потребуется дополнительная обработка или хранение данных.

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

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

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