Краткий экскурс в GraphQL

Автор: admin от 21-09-2018, 18:45, посмотрело: 130

Привет, Хабр!



Краткий экскурс в GraphQL

Именно кратким экскурсом в язык запросов GraphQL послужит вам книга Алекса Бэнкса и Евы Порселло, которую мы отдали в перевод пару дней назад. Книга этих же авторов о React и Redux стала настоящим бестселлером (ждем 5-й тираж из типографии). Кстати, спасибо всем, кто указал нам на неточности в коде и терминах ;) книгу по столь быстро устаревающей технологии мы делали излишне быстро.



Автор сегодняшней статьи Робин Вирух также работает над книгой о GraphQL и библиотеках для этого языка, а в сегодняшней статье кратко объясняет достоинства и характерные особенности GraphQL как альтернативы REST

[1] [2]
  • Shopify [1] [2]

  • Twitter

  • Coursera

  • Yelp

  • Wordpress

  • The New York Times

  • Samsara

  • и др



  • Когда Facebook разработала GraphQL и предоставила в открытый доступ, другие компании, создававшие мобильные приложения, также сталкивались со схожими проблемами. Именно так Netflix и создал проект Falcor, который можно считать альтернативой GraphQL. Что в лишний раз подтверждает, что для современных приложений нужны именно такие решения как GraphQL и Falcor.



    Единый источник истины



    В приложениях GraphQL существует истина в последней инстанции: это схема GraphQL. Именно она – центральный источник, в котором описаны все доступные данные. Тогда как схема GraphQL обычно определяется на стороне сервера, клиенты могут читать (запрашивать) и записывать (изменять) данные на основании этой схемы. Таким образом, серверное приложение, в сущности, предоставляет исчерпывающую информацию, имеющуюся на сервере, а клиентская сторона запрашивает лишь то, что требуется, формулируя запросы на GraphQL, либо изменяет мелкие информационные фрагменты, пользуясь изменениями GraphQL.



    GraphQL следует современным тенденциям



    GraphQL следует современным тенденциям в создании приложений. У вас на бэкенде может быть всего одно приложение, но зачастую бывает так, что этим бэкендом пользуется множество разных клиентов (веб-клиент, мобильное устройство, умные часы…) и все они зависят от данных, хранящихся в бэкендовом приложении. Следовательно, GraphQL может помочь не только подружить «оба мира», но и удовлетворить требования каждого клиента (связанные, например, с использованием сети, вложенными взаимосвязями данных, выборкой лишь требуемых данных) без необходимости создавать выделенный API для каждого типа клиента.



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



    Как сшивается схема GraphQL



    Благодаря сшиванию можно собирать одну схему из множества других. Когда можно попасть в такую ситуацию? Допустим, ваш бэкенд реализован при помощи микросервисной архитектуры. Каждый микросервис обрабатывает бизнес-логику и данные, относящиеся к конкретной предметной области. Следовательно, каждый микросервис может определить собственную схему GraphQL. После этого понадобится их сшить, чтобы собрать из всех схем одну, к которой и будет обращаться клиентское приложение. В конце концов, у каждого микросервиса может быть собственный терминал GraphQL, а один шлюз GraphQL API будет консолидировать все схемы в одну глобальную, чтобы предоставить ее клиентским приложениям.



    Интроспекция GraphQL



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



    Сильно типизированный GraphQL



    GraphQL – это сильно типизированный язык запросов, написанный на выразительном языке определения схем (SDL) для GraphQL. Этот язык обладает теми же достоинствами, что и любой сильнго типизированный язык программирования. Он менее подвержен ошибкам, допускает валидацию во время компиляции и позволяет рассчитывать на интеграцию с поддерживаемыми возможностями IDE/редактора, такими, как автозавершение и поддержка ввода.



    Версионирование GraphQL



    В GraphQL нет таких версий API, к которым мы привыкли в REST. В REST нормально предлагать несколько версий одного API (напр. api.domain.com/v1/, api.domain.com/v2/), поскольку ресурсы или их структура со временем могут меняться. В GraphQL можно перевести API в нерекомендуемые на уровне поля. Следовательно, клиент получает предупреждение, когда обращается к нерекомендуемому полю. Спустя некоторое время нерекомендуемое поле может быть исключено из схемы, тогда больше никакие клиенты не будут его использовать. Таким образом, API GraphQL может развиваться без необходимости версионирования.



    Растущая экосистема GraphQL



    Экосистема GraphQL растет. Речь не только об интеграциях с редакторами и IDE, связанных с сильно типизированной природой GraphQL; для GraphQL как такового появляются новые полноценные варианты применения. Например, можно припомнить Postman, применявшийся при работе с REST API, а теперь для этой же цели, но с GraphQL API применяется GraphiQL или GraphQL Playground. Также для вас найдутся различные библиотеки, например, Gatsby.js, генератор статических веб-сайтов для React, использующий GraphQL. Например, Gatsby.js позволяет написать движок для блога, наполняющий ваш блог контентом во время сборки через GraphQL API. Следовательно, у вас также будут CMS без клиентской части (напр., GraphCMS), предоставляющие контент (для блога) через GraphQL. API. Однако, в этой области развиваются не только технологические компоненты. Как грибы после дождя растут конференции, митапы и сообщества, посвященные GraphQL, также не составляет труда найти по нему новостные рассылки и подкасты.



    Если я перехожу на GraphQL – то иду «олл-ин»?



    Добавляя GraphQL в имеющийся технологический стек, мы, конечно, не идем «олл-ин». Мигрируя с монолитного бэкендового приложения на микросервисную архитектуру, самое дело подставить API GraphQL для новоиспеченных микросервисов. Ведь именно при наличии множества микросервисов, вы с вашей командой смело можете внедрить шлюз GraphQL, сшивая схемы и консолидируя их в одну глобальную схему. Но шлюз API можно использовать не только с микросервисами, но и с монолитным REST-приложением. Именно так можно объединить все ваши API на одном шлюзе и шаг за шагом мигрировать на GraphQL.



    Недостатки GraphQL



    Далее обсудим некоторые недостатки, связанные с использованием GraphQL.



    Сложность запросов GraphQL



    Иногда GraphQL используют неправильно, пытаюсь заменить им базу данных на стороне сервера. Нет, так не пойдет. GraphQL – просто язык запросов. Когда на стороне сервера запрос необходимо разрешить данными, обычно найдется не зависящая от GraphQL реализация, обеспечивающая доступ к базе данных. GraphQL в данном случае индифферентен. Более того, GraphQL не устраняет никаких узких мест с производительностью, когда вам требуется обращаться в одном запросе сразу ко множеству полей (авторы, статьи, комментарии). Независимо от того, в какой архитектуре совершался запрос – RESTful или GraphQL, вам все равно придется извлекать из источника различные поля.



    Таким образом, у нас возникнет проблема, если клиент пошлет кучу запросов сразу ко множеству вложенных полей. Зачастую разработчики клиентской части не знают, сколько различных запросов к базе данных приходится обрабатывать в серверном приложении, если начинаются массовые обращения к данным. Именно на такие случаи нужен механизм (например, максимальная глубина запросов, взвешивание сложности запросов, избегание рекурсии, постоянные запросы), чтобы предотвратить поток слишком дорогостоящих запросов со стороны клиента.



    Ограничение скорости в GraphQL



    Другая проблема – ограничение скорости. Тогда как в REST сравнительно просто сказать «допускается не более чем столько запросов в день», сложно сформулировать подобную инструкцию для отдельных операций GraphQL, так как здесь бывают не только «затратные» и «незатратные» операции, но и множество промежуточных градаций. Именно для таких случаев компании, предоставляющие публичные API GraphQL предлагают собственные расчеты по ограничению скорости, зачастую сводимые к вышеупомянутым максимальным значениям глубины запросов и взвешиванию сложности запросов.



    Кэширование GraphQL



    При работе с GraphQL реализация упрощенного кэша оказывается гораздо сложнее, чем в REST. Работая с REST, мы обращаемся к ресурсам по URL и, следовательно, можем организовать кэширование на уровне ресурсов, так как URL ресурса может служить его идентификатором. В GraphQL это усложняется, так как все запросы могут получаться разными, даже притом, что все оперируют одним и тем же объектом. В одном запросе вы можете затребовать имя автора, а в следующем – не только имя автора, но и адрес его электронной почты. Именно для таких случаев вам понадобится более филигранный кэш на уровне полей, а реализовать его не так-то просто. Однако, большинство библиотек, построенных поверх GraphQL, предлагают такие механизмы кэширования прямо «из коробки».



    Почему не REST?



    GraphQL – это альтернатива широко распространенной архитектуре REST, соединяющей клиентские и серверные приложения. Выше мы неоднократно упоминали REST – так каковы же очевидные выгоды GraphQL, ради которых его стоит предпочесть REST?

    Поскольку в REST предусматривается URL для каждого ресурса, зачастую у нас получаются неэффективные каскадирующие запросы. Сначала мы выбираем объект «автор», идентифицируемый по id, а затем выбираем все статьи этого автора, помеченные его id. В GraphQL все это можно сделать всего за один запрос, и в этом отношении он гораздо эффективнее. Более того, если вы хотите выбрать все статьи автора, а информацию об авторе не трогать, то GraphQL позволяет вам вычленить лишь те информационные фрагменты, которые вам нужны.



    Современные клиентские приложения не рассчитаны на работу с серверными приложениями, устроенными по принципу REST. Возьмем к примеру результат поиска на платформе Airbnb. Вам выводятся дома, впечатления о них и другие сопряженные ресурсы. Дома и впечатления сами про себе будут REST-ресурсами, поэтому в REST-архитектуре вам потребуется выполнять множество запросов по сети. Если же у вас, напротив, будет GraphQL API, то все сущности можно будет затребовать в одном запросе GraphQL, соотнеся их бок о бок (например, дома и впечатления), либо в виде вложенных взаимосвязей (напр., статьи от авторов).



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



    Наконец, остаются и такие ситуации, в которых REST – ценный способ сочленения клиентских и серверных приложений. Зачастую приложения завязаны на работу с ресурсами, и в них не требуется всех возможностей столь гибкого языка запросов как GraphQL. Однако, рекомендую хотя бы попробовать GraphQL, когда будете приступать к разработке вашей следующей клиент-серверной архитектуры.


    Источник: Хабр / Интересные публикации

    Категория: Веб-разработка

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *