Это не совсем образовательный пост о «Что такое GraphQL» или почему он так крут, или даже об опыте использования GraphQL в продакшне. Я просто хочу вкратце изложить свое мнение о том, что это за технология, и возможный практичный подход к ее применению.
Итак, GraphQL — это язык запросов, применяемый Facebook для извлечения данных из графовых СУБД. Язык оказался настолько удачным, что потенциальная сфера его применения значительно шире — его называют «убийцей REST» и даже прикрутили его к реакту в качестве очередного движка управлениями моделями данных. Совсем вкратце о том, что такое 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
