Эта статья написана Андреем Анисимовым, вице-президентом по технологиям компании 8base.

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

Перенесемся на несколько лет вперед - браузеры уже повзрослели и теперь поддерживают HTML5 и JavaScript, открывая расширенные возможности на стороне клиента. В этот момент появился фронтенд-разработчик. Хотя разработчики начали расходиться в своих ролях и обязанностях, чтобы идти в ногу с развивающимся технологическим прогрессом, монолитные фреймворки, такие как PHP, Ruby-on-Rails и ASP.NET, продолжали доминировать в экосфере разработчиков благодаря своей простоте, рентабельности и повсеместное использование наследия.

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

Первый подход к API

Чтобы учесть возникающую тенденцию, был принят новый подход `` прежде всего API '': вместо монолитных одноуровневых приложений внутренние разработчики теперь могли создавать надежный API, к которому могут подключаться разнообразные полнофункциональные собственные или сторонние клиентские приложения. . Благодаря своей простоте и элегантности REST стал де-факто стандартом для реализации API в большинстве современных веб-приложений и мобильных приложений. Между тем, разработчики начали сильно тяготеть либо к back-end, либо к front-end с расширением расхождения карьерных путей и технологических стеков.

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

Для решения этих проблем в 2012 году Facebook разработал новый стандарт под названием GraphQL, который опубликовал в 2015 году. GraphQL позволяет использовать язык запросов для API. Его все чаще используют многие известные команды разработчиков в таких компаниях, как AirBnB, Stripe, GitHub, Pinterest, Shopify и Intuit.

Приобретение GraphQL

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

GraphQL против. ОТДЫХ

Давайте сравним GraphQL и REST на простом примере: создание онлайн-блога. При отображении экрана отдельной статьи в блоге нам необходимо показать содержание сообщения, аватар и имя автора, список комментариев, а также имя и аватар каждого автора комментария.

С помощью REST нам нужно будет запрограммировать следующие вызовы API:

  1. GET / article /: id для получения содержания сообщения
  2. GET / users /: id, чтобы получить URL-адрес аватара и имя автора
  3. ПОЛУЧИТЕ / article /: id / comments, чтобы получить список комментариев - будем надеяться, что внутренние разработчики включили имя автора комментария и аватар. В противном случае нам придется делать (4)
  4. GET / users /: id для каждого комментария, чтобы получить URL-адрес аватара и имя автора комментария

Обратите внимание, что недостаточная выборка (когда один запрос не дает нам всех необходимых данных) и избыточная выборка (например, вызов / users /: id возвращает больше информации, чем нам нужно отображать), а также повышенная сложность фронтальной -end code, необходимы для организации серии зависимых вызовов API.

С GraphQL всю информацию можно получить в одном запросе, учитывая, что разработчики API выразили отношения между сообщениями, пользователями и комментариями в схеме GraphQL API. Кроме того, в ответ включаются только запрошенные поля, что уменьшает его размер. Ниже приведен пример запроса GraphQL, который предоставляет нам всю информацию в одном запросе:

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

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

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

Использование GraphQL с 8base

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

8base's GraphQL API решает эту проблему автоматически, предоставляя интерфейсным и мобильным разработчикам инструменты для настройки мощного бэкенда GraphQL, который значительно ускоряет создание приложений. Для каждой таблицы, определенной в вашем рабочем пространстве, 8base автоматически генерирует следующие операции GraphQL:

  • Получить отдельный объект по идентификатору или любому уникальному полю

  • Получите список объектов на основе критериев фильтрации, сортировки, разбивки на страницы и полнотекстового поиска

  • Создание, обновление, удаление объекта

  • Подпишитесь на события с данными в реальном времени

Все эти операции очень хорошо работают с объектными отношениями, позволяя разработчикам запрашивать, создавать и обновлять дочерние объекты вместе со своими родителями:

Доступ к каждой таблице данных и полю можно контролировать с помощью ролевой защиты:

Фреймворк расширяемости 8base

Готовый CRUD удобен, но для многих приложений этого недостаточно. Большинству приложений требуется какая-то настраиваемая логика на стороне сервера (например, отправка электронной почты, подключение к стороннему API, запуск алгоритма и т. Д.). Традиционно для выполнения этой задачи вам потребуются серверные разработчики, которые будут писать код, настраивать и масштабировать базовую вычислительную инфраструктуру.

8base Logic позволяет определять, развертывать и выполнять пользовательскую логику на стороне сервера в виде бессерверных функций. Код может быть написан на JavaScript или TypeScript - языках, которые интерфейсные разработчики уже используют ежедневно. Развертывание, инициализация и выполнение функций происходит автоматически внутри платформы 8base - не нужно беспокоиться о начальной настройке или текущем масштабировании внутренних рабочих нагрузок.

А как насчет файлов?

Ни GraphQL, ни REST не предлагают никакой помощи, когда дело доходит до работы с файлами. Современные приложения требуют от разработчиков разрешенного хранения файлов и обмена ими, а также связывания файлов с объектами данных. Помимо других задач, изменение размера изображений, создание эскизов и их обслуживание через сеть распространения контента (CDN) также сталкиваются с трудностями.

8base GraphQL API предоставляет встроенные возможности управления файлами, что упрощает работу с файлами любого типа. 8base Data Builder позволяет пользователям определять поле Тип файла в любой таблице, чтобы иметь возможность хранить файлы и работать с ними, как с обычными данными. Благодаря встроенной интеграции Filestack, 8base предлагает множество инструментов для работы с файлами и документами: надежное средство выбора файлов на стороне клиента, быстрое получение контента, операции с изображениями, создание эскизов, поиск в документе, оптическое распознавание символов (OCR), распознавание лиц. и более.

Вот как можно запросить информацию об аватаре пользователя с помощью 8base GraphQL API:

Попробуйте 8base сами

8base дает фронтенд-разработчикам возможность создавать и запускать современные веб-и мобильные приложения, не будучи зависимыми от больших кросс-функциональных команд бэкэнд-разработчиков и сотрудников DevOps. Но не верьте нам на слово, попробуйте сами, заполнив Руководство по быстрому запуску, чтобы запустить демонстрационное приложение React менее чем за 10 минут.

Связаться с нами!

Чтобы начать работу с 8base или просто получить дополнительную информацию, посетите www.8base.com, docs.8base.com, подпишитесь на нас в Twitter по адресу @ 8baseinc или напишите нам по адресу [email protected].