GraphQL как универсальный RPC

Это не совсем образовательный пост о «Что такое GraphQL ^[1]» или почему он так крут ^[2], или даже об опыте использования GraphQL в продакшне ^[3]. Я просто хочу вкратце изложить свое мнение о том, что это за технология, и возможный практичный подход к ее применению.

Итак, GraphQL — это язык запросов, применяемый Facebook для извлечения данных из графовых СУБД. Язык оказался настолько удачным, что потенциальная сфера его применения значительно шире — его называют «убийцей REST» и даже прикрутили его к реакту ^[4] в качестве очередного движка управлениями моделями данных. Совсем вкратце о том, что такое GraphQL:

— запрос — это список полей, которые нужно вернуть в ответе. Возвращаются только те поля, которые были запрошены
— поле может оказаться методом с одноименным названием — тогда прямо в запросе указываются параметры этого метода: {name, surname, age, getLikesCount(since: «01.01.2016»)}
— если значение поля или метода — объект, то для него так же надо явно указать список полей: {name, surname, age, bestFriend: {name}}

Есть много разных мнений о том, что именно в нем такое инновационное, но, я думаю, что самая интересная идея вот в чем:

Модель данных — это частный случай модели API

И в самом деле, если в произвольном json заменить поля на методы с пустым списком параметров, то получится какое-то урезанное API:

{
  name: "John",
  age: 25
  friends: [{
    name: "Jenny",
    age: 24
  }]
}

превращается в

interface Human {
  name(): string
  age(): int
  friends: Human[]
}

Этот пример демонструет важное следствие — если API и данные — это одно и то же, то API может возвращать ссылки на другие API, т.е. на объекты, предоставляющие методы, возвращающие данные (или другие API). Важный момент — методы вовсе не обязаны быть идемпотентными, это вполне может быть update/delete или просто вызов некой бизнес-логики.

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

— строгая типизация
— поддержка интерфейсов
— документированное представление схемы в виде структуры данных

мы получаем, что GraphQL позволяет выставить в сеть произвольный объект! И, в частности, активную доменную модель, самописную или собранную при помощи ORM типа Hibernate

Многим не нравится избыточность GraphQL, его набор фишек и примочек, которыми он оброс за время использования его в фейсбуке. Многие из них имеют смысл только в контексте node.js и конкретного стиля разработки. Но — если у нас есть схема и мы сказали RPC, то очевидное решение — кодогенерация. Если многословные запросы со всем этим `query`, `mutation` и объявлением переменных будут скрыты за API, то этот недостаток нивелируется.

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

Осталось его написать :)

Спасибо.

Автор: Scf

Источник ^[5]