Если вы знаете о веб-разработке, то совершенно невозможно, чтобы вы не знали о Rest-API. Rest-API были основой веб-разработки, сегодня большинство приложений, которые мы создаем, или веб-сайты, которые мы используем ежедневно, работают на Rest-API.
Люди, которые знают о Rest-API, наверняка слышали о GraphQL, а некоторые могут быть не знакомы с этим термином. Как бы то ни было, в конце этой статьи вы узнаете что-то новое о GraphQL и, самое главное, это даст вам совершенно новый взгляд на него.
На YouTube есть очень интересный документальный фильм, объясняющий, почему и как Facebook начал работать над проектом GraphQL и как он на самом деле спас мобильное приложение Facebook. (Https://www.youtube.com/watch?v=783ccP__No8)
Итак, давайте углубимся, чтобы узнать больше об этой новой популярной тенденции -
Если вы до сих пор слышали, что GraphQL заменяет Rest-API, то я бы сказал, что необходимо изменить нашу точку зрения. Назвать GraphQL убийцей REST - это чрезмерное упрощение. Более тонкий подход заключается в том, что по мере развития сети REST в определенных условиях проявляет признаки напряжения. GraphQL был создан, чтобы облегчить напряжение.
Тогда что же такое GraphQL?
GraphQL - это спецификация (спецификация) для взаимодействия клиент-сервер. Однако важно понимать, что GraphQL не является реализацией. Вы не можете загрузить и установить сам GraphQL. Вместо этого это просто спецификация языка и синтаксиса. Фактически, он не зависит от стека. Вы можете использовать его вместе с любым языком программирования, базой данных, веб-фреймворком или библиотекой пользовательского интерфейса. Эталонная реализация GraphQL написана на JavaScript как на сервере, так и на стороне клиента. Однако ничто не мешает вам использовать его в любом приложении, независимо от языка. Серверные библиотеки GraphQL существуют на множестве разных языков, включая C #, Clojure, Elixir, Erlang, Go, Groovy, Java, JavaScript, .NET, PHP, Python, Scala и Ruby.
GraphQL часто называют языком декларативной выборки данных. Мы запрашиваем данные в определенной форме, мы получаем данные обратно в этой форме. Ни больше ни меньше.
Под этим мы подразумеваем, что разработчики будут перечислять свои требования к данным как данные, которые им нужны, не фокусируясь на том, как они собираются их получить.
Это более декларативно и, вероятно, даст более быстрый ответ, учитывая, что посторонние данные не забирается.
Многие компании перешли с RESTful на GraphQL API для внутреннего использования: Atlassian, Coursera, Facebook, Intuit, KLM, Meteor, NBC News, PayPal, Pinterest, Shopify, The New York Times, Twitter, Wayfair и Yelp, и список можно продолжить. на о. Они утверждают, что им это нравится и им очень нравится.
Другие компании перешли на GraphQL не только внутренние, но и внешние API: AWS, Yelp, GitHub, Facebook и Shopify среди других.
GitHub даже не стал беспокоиться о REST API. Их версия 4 предназначена только для GraphQL.
Интересно, что у большинства компаний, получивших выгоду от GraphQL, есть следующие общие черты:
- У них несколько клиентов, включая мобильные
- Они переходят или уже используют архитектуру микросервисов
- Их устаревшие API-интерфейсы REST разрастались и усложнялись.
- Они хотят убрать зависимость клиентских команд от API-команд.
- Они ценят хорошую документацию по API и заботятся об опыте разработчика.
Теперь давайте сосредоточимся на том, почему GraphQL так быстро стал популярным -
Множественные запросы, избыточная и неполная выборка:
Каждый раз, когда вы делаете запрос к REST API, вы отправляете этот запрос на конкретную конечную точку. Если вам нужна информация о фильмах в библиотеке, например, вы можете сделать запрос на «movies.com/api/movies
В архитектуре REST различные конечные точки связаны гиперссылками, поэтому, если вы хотите указать дату выпуска определенного фильма, вам нужно будет посетить унифицированный идентификатор ресурса (URI) этого фильма. Например, movies.com/api/movies/avatar предоставит вам дату выпуска вместе с подробной информацией о фильме Аватар, такой как информация о режиссере, продюсере и т. Д. (ясный случай перегрузки)
Если вам нужна информация о режиссере фильма, вам нужно будет сделать другой запрос API в архитектуре REST. Например, этот запрос может идти по адресу movies.com/api/directors/ ‹director_id›
Как видите, мы делаем несколько запросов к API, чтобы получить дату выпуска фильма и его режиссера. Более того, REST API, вероятно, получает избыточную информацию, которая нам не нужна и которую мы не будем использовать.
Предположим, завтра мы хотим добавить одну новую функцию вместе с информацией о режиссерах (movies.com/api/directors/ ‹director_id›), нам нужно показать все остальные фильмы, снятые тем же человеком, тогда нам нужно сделать несколько дополнительных звонков чтобы это произошло. Ясный случай недостаточной выборки. Решение GraphQL для неполной выборки состоит в том, чтобы определить вложенный запрос и затем запросить данные за одну выборку.
Повышенная производительность:
Не только инженеры получают пользу от GraphQL. Пользователи тоже выигрывают, потому что производительность может улучшиться за счет следующего:
· Сниженная полезная нагрузка (клиенты запрашивают только то, что им нужно, без изменений на бэкэнде)
· Несколько запросов объединены в один, что снижает накладные расходы сети
· Кэширование клиентов, а также пакетирование и кэширование бэкэнда стало проще с помощью инструментов
· Предварительная выборка (например, предварительная выборка Apollo)
· Оптимистичные обновления пользовательского интерфейса
Не верьте мне на слово. PayPal модернизировал свою кассу с помощью GraphQL.
Улучшенные возможности для разработчиков.
GraphQL предлагает более удобные возможности для разработчиков (DX). С GraphQL инженерам нужно меньше думать об извлечении данных.
Важно соблюдать договор между фронтендом и бэкэндом. REST API должны заботиться о том, чтобы не нарушить код клиента, потому что
клиенты не могут контролировать ответ. И наоборот, GraphQL предоставляет управление клиенту, поэтому GraphQL может часто обновляться без
внесения критических изменений с помощью новых типов. GraphQL - это API без версий благодаря схемам.
Повышенная безопасность, строгие типы и проверка:
GraphQL предлагает повышенную безопасность по сравнению с JSON RESTful API по двум основным причинам: строго типизированная схема (например, проверка данных и отсутствие SQL-инъекций из-за неправильного типа ) и возможность точно определять данные, необходимые клиентам (отсутствие непреднамеренной утечки данных).
Статическая проверка - еще один плюс, который экономит время инженеров и повышает уверенность во время рефакторинга.
Такие инструменты, как eslint-plugin-graphql, проверяют запросы GraphQL к схемам, чтобы предупреждать инженеров о любых изменениях в серверной части,
и чтобы инженеры серверной части могли убедиться, что они не нарушили какой-либо клиентский код (что случилось с меня более чем в несколько раз).
График Язык запросов QL -
SQL или язык структурированных запросов - это предметно-ориентированный язык, используемый для доступа, управления и манипулирования данными в базе данных.
Один запрос GraphQL может возвращать связанные данные. Как и SQL, вы можете использовать запросы GraphQL для изменения или удаления данных. В конце концов, QL в SQL и GraphQL означают одно и то же: язык запросов, за исключением того, что GraphQL и SQL совершенно разные.
GraphQL стандартизирован в соответствии с его спецификацией. Неважно, какой язык вы используете: запрос GraphQL - это запрос GraphQL. Запросы - это просто строки, которые отправляются в теле запроса POST на конечную точку GraphQL.
Ниже приведен пример запроса GraphQL, строка, написанная на языке запросов GraphQL. Мы указали запрошенное название, режиссера и дату выпуска фильма с идентификатором 1 и в ответ получили информацию только из трех полей. Мы получили то, о чем просили. Ни больше ни меньше.
Для взаимодействия с API GraphQL доступно несколько различных инструментов, например GraphQL и GraphQL Playground. Эти инструменты позволяют писать запросы на языке запросов GraphQL, отправлять эти запросы конечным точкам GraphQL и проверять ответ JSON.
С GraphQL мы можем выполнять разные типы операций. Три основных операции: Запрос, Мутация и Подписка. У нас уже есть, как работает операция запроса, давайте посмотрим оставшиеся две операции.
#Mutation:
Чтобы изменить данные, мы можем отправить мутации. Мутации очень похожи на запросы, но их цель - изменить что-то в общем состоянии приложения. Данные, необходимые для выполнения изменения, могут быть отправлены непосредственно с мутацией, как показано ниже. Здесь мы пытаемся добавить песню и передаем информацию о песне с тремя параметрами. После выполнения запроса ниже будет добавлена песня, и в ответ мы получим информацию об идентификаторе, названии и numberOne.
№ подписки:
Третий тип операций, доступных с GraphQL, - это подписка. Бывают случаи, когда клиент может захотеть получать обновления в реальном времени с сервера. Подписка позволяет нам прослушивать GraphQL API на предмет изменений данных в реальном времени. Ниже приведен пример подписки, которая всегда прослушивает любую новую песню, которая будет добавлена / изменена или удалена.
Так же, как мутация и запрос, подписка является корневым типом. Изменения данных, которые могут прослушивать клиенты, определены в схеме API как поля типа subscription.
Как запрос GraphQL выполняется в серверной части?
Документ запроса - это строка. Когда мы отправляем запрос в GraphQL API, эта строка анализируется в абстрактное синтаксическое дерево и проверяется перед запуском операции. Абстрактное синтаксическое дерево или AST - это иерархический объект, представляющий наш запрос. AST - это объект, который содержит вложенные поля, которые представляют детали запроса GraphQL.
Первый шаг в этом процессе - разбить строку на кучу более мелких частей. Это включает в себя анализ ключевых слов, аргументов и даже скобок и двоеточий в набор отдельных токенов. Этот процесс называется лексическим анализом или лексическим анализом. Затем лексированный запрос анализируется в AST. Запрос намного проще динамически изменять и проверять как AST.
GraphQL может пройти через этот AST и проверить его детали на соответствие языку GraphQL и текущей схеме. Если синтаксис языка запросов правильный и схема содержит поля и типы, которые мы запрашиваем, операция выполняется. В противном случае вместо этого возвращается конкретная ошибка.
Заключение -
Мы увидели, что такое GraphQL, что такое языки запросов, различные типы операций и как выполняется запрос. Хотя мы видели, когда использовать GraphQL, а также говорили о преимуществах, которые мы получаем с GraphQL, но, как и любой другой технологический стек, GraphQL также предлагает некоторые сценарии, которые могут быть причиной беспокойства для вашего приложения, и мы должны знать, как их исправить. Мне нравится статья ниже, в которой объясняются распространенные проблемы в graphQL и способы их решения.
