Как перестать работать прокладкой: разработка API с GraphQL

7 минут

Что такое современная серверная разработка в 2019 году? Чаще всего это разработка API. Распараллеливание бизнес-процессов, разбивка огромных приложений на маленькие микросервисы, вынос большинства пользовательских интерфейсов в смартфоны и браузеры — все эти тенденции последних десяти лет привели к тому, что разработчики бэкенда почти все свое время пилят апихи.

API можно реализовывать разными способами — SOAP, RPC, REST, JSONP. Но все эти способы объединяет одно: излишние временные затраты на разработку и негибкость методологии.

Ахтунг! Чтобы понять, что дальше, хорошо бы иметь хотя бы элементарные представления о разработке серверного API.

Я есть CRUD: рутина в разработке API

Знаменитое отношение Парето (когда 80% результата приносят 20% процентов работы) работает и при разработке API. 80% кода для апишек решает крайне унылые однообразные задачи и сжирает кучу времени разработчиков.

Что же это за унылые операции?

  1. Прочитать что-то из базы данных и вернуть пользователю.
  2. Получить данные, проверить их правильность и создать новую запись в базе.
  3. Получить данные, проверить их опять и обновить старые записи.
  4. Удалить ненужные записи.

Комплекс этих четырёх действий называется CRUD (create-read-update-delete), они неизбежны в любом проекте и вызывают тоску на лице у разрабов. Избежать работы над CRUD-кодом невозможно — эти операции всегда есть в любой информационной системе. А выполнять чтения-записи-удаления просто так нельзя — каждое действие требует предварительных проверок на адекватность данных, на наличие доступа к системам и на непротиворечивость состояний внутри базы.

Больше страданий богу страданий: тонна однообразного кода API

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

  1. POST /users — создать юзера
  2. GET /users/1 — получить данные о юзере с номером 1. Запрос на создание нужно проверить, данные отфильтровать. Не забываем, что у клиента должен быть доступ к функции создания новых юзеров, так что здесь начинаем делать контроль доступа.
  3. PUT /users/1 — обновим состояние юзера с номером 1 (права опять надо проверить! И данные тоже.)
  4. PATH /users/1 — тоже обновление юзера, но чуть другое (опять права и данные)
  5. DELETE /users/1 — удаление юзера (тут уже проверяются только права)

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

API c GraphQL: ставим запятую в «писать унылый код не могу оптимизировать рутину»

Многие годы в этом предложении инженеры-бэкендеры ставили запятую после слова «код». А потом засучивали рукава и принимались за написание огромного количества однотипных проверок, правил валидации данных и систем контроля доступа к API.

Но, пока подавляющее большинство бэкендеров работало руками по 10 часов в сутки, пиля однообразный код, небольшая группа инженеров внутри Facebook работала головой.

Спецы из крупнейшей в мире социальной сети придумали простую концепцию — создать универсальный язык запросов (примерно как SQL), с помощью которого программы смогут обмениваться данными и командами в любых комбинациях и вариантах. При этом, по сути, сама разработка сводится к написанию лишь одной точки доступа извне, которая умеет принимать команды и делать с данными все, что угодно. Эту революционную технологию назвали GraphQL.

Что же с проверками прав доступа и валидаторами данных? Они, конечно, никуда не делись. Но писать их стало гораздо проще. Достаточно просто встроить все правила валидации и контроля доступа в готовый интерпретатор этого самого языка GraphQL.

Итого: писать унылый код не могу, оптимизировать рутину!

Как пилить API c GraphQL

Допустим, мы пилим API для работы с пользователями из примера выше. Для этого мы реализуем обработчик запросов GraphQL и вешаем его на адрес, скажем /graphql. Все эти POST|PUT|GET /users не нужны — у нас теперь одна входная точка для всех запросов.

Допустим, мы хотим прочитать данные о пользователе с номером 1. Мы формируем запрос на языке GraphQL и отправляем его на адрес /graphql.

{

users(id:1) {

Id,

email

}

}

Этот запрос прочитает на сервере ID и почту юзера под номером 1 и вернет его клиенту.

{

users(limit: 100, offset: 0) {

Id,

email,

name

}

}

А этот запрос прочитает данные о первых 100 пользователях в базе и вернет их ID, почту и имя.

И так далее (вы же уловили идею?). Можно написать запросы для удаления, создания, редактирования любых данных — все операции будут выполняться на одном адресе и с одинаковым синтаксисом.

Как внедрить GraphQL у себя в проекте?

  1. Для начала познакомьтесь с доками и учебными примерами.
  2. После этого погуглите библиотеку, реализующую GraphQL под ваш любимый язык программирования (да-да, все уже написано — бери и пользуйся).
  3. Немного поупражняйтесь с запросами и привыкните думать об API не в терминах RPC или REST, а в терминах GraphQL. Сперва мозг будет сопротивляться, но через пару часов вы все поймете.
  4. Начинайте писать код под вашу систему!

Ещё плюшечки GraphQL

  1. GraphQL — это новая бурно развивающаяся технология. Каждые несколько месяцев выходят новые инструменты, библиотеки и фреймворки. С этим очень интересно работать!
  2. GraphQL реально ускоряет разработку API — весь код пишется 1 раз, опирается на довольно надежные библиотеки, его легко писать и поддерживать.
  3. Экономия трафика! GraphQL позволяет очень точно указывать, какие данные вы хотите получить с сервера. Что серьёзно минимизирует накладные расходы на передачу лишней инфы.
  4. Авторитетные инженеры говорят, что в скором времени подавляющее большинство серверных API будет писаться именно с применением этого подхода. Позиции REST все еще сильны, но адепты нового метода активно щемят ортодоксов. Такие тектонические сдвиги в мире серверных API уже происходили в прошлом (кто-нибудь помнит XML RPC?). И GraphQL прямо сейчас снова меняет ландшафт серверной разработки.

Ложка IT-дёгтя

Как и у всех вещей в этой жизни, у GraphQL есть и минусы.

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

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

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

И снова в бочку мёда разработки API с GraphQL

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

Group 40Group 44Group 43Group 46Group 41Group 27Group 42Group 39