Стоит ли использовать везде GraphQL?

Question

[DeniSidorenko]

Добрый день, предыдущий проект реализовал методом REST API, контроллеры, роуты. В новом проекте решил использовать GraphQL. Понравился query который может быстро и легко доставать нужные данные. Но вот вопрос надо ли теперь использовать его везде? К примеру для получения продуктов он отлично подходит. А к примеру для добавления продуктов, регистрации пользователей мне показалось удобнее использовать REST API. К примеру для авторизации где требуется middleware .
Как по мне для мутации он не так подходит. Вопрос стоит ли его использовать везде или только для получения сложных запросов. Вопрос может и странный ибо никаких ограничений в этом плане нет, но сколько докладов я смотрел везде отказывались о REST API в пользу Graphql.

Comments

[Станислав Макаров]

но сколько докладов я смотрел везде отказывались о REST API в пользу Graphql

в докладах про GraphQL?)

[DeniSidorenko]

Станислав Макаров, Да) Некоторые доклады и вовсе про то что теперь и редакс можно выбрасить :D :D
Но на амом деле да, в большинстве случаев в докладах указывается что это полная замена REST API
Это конечно можно без проблем, просто как по мне в некоторых местах rest api лучше подойдет)

[shurshur]

DeniSidorenko,

сколько докладов я смотрел везде отказывались о REST API в пользу Graphql

Крайне редко люди делают доклад о том, как они попробовали новую технологию и вообще не стали на неё переходить. Делать из подобных наблюдений выводы - когнитивная ошибка.

[Bunga]

Чем мне нравится JSON-RPC - нет никаких мук раздумий "а как правильно сделать то и это на ресте/графкуле/другой модный протокол". Сразу берёшь и делаешь что тебе надо

[ayazer]

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

Answer 1

[Дмитрий Беляев]

Если Вы не пишите внешнее или публичное API, то GraphQL и REST - будут крайне отвратительным выбором. Они ограничивают Вас в низкоуровневом CRUD, создавая больше проблем, чем решают, а главное затрудняют выражать Ваше API в терминах доменной области.
Посмотрите в сторону RPC протоколов, и посмотрите как элегантно на них можно описать конкретно Ваш домен. Да и выбор тут огромен: Apache Thrift, gRPC, JSON-RPC, а так же мой любимый, но почему-то малоизвестный в русскоязычном интернете E/A/?T (расшифровывается как entity/action/optional-target)

Comments

[Quty]

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

2. Они ограничивают Вас в низкоуровневом CRUD, создавая больше проблем, чем решают

   Если не затруднит, могли бы привести пример? Кажется, речь о том, что CRUD у́же предметной области и последнюю приходится подгонять под этот самый CRUD. Но ведь мутации в GQL +- тоже самое, что описание методов в RPC, разве нет? Можно описать метод с любым названием, отражающим суть use-case, который принимает определенный набор параметров и что-то возвращает.
   

3. а так же мой любимый, но почему-то малоизвестный в русскоязычном интернете E/A/?T

   Что-то ничего адекватного по запросу

   rpc entity action target

   не смог найти. Буду благодарен, если поделитесь ссылками на материал.
   

[Just Me]

технологии типа gRPC и JSON-RPC известны давно. Если они до сих пор широко не применяются (а стандартом де факто выступает обычное REST API), то значит либо они не лучше REST API, либо существуют объективные причины, почему их не выгодно использовать

[Дмитрий Беляев]

Quty,

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

Да, это API предоставляемое третьим лицам, деятельность которых лежит за пределами моей компании/домена/другого бизнес-юнита. REST или GraphQL тут выигрывают по 2 параметрам:
Во-первых, я не знаю доменную область пользователей моего API, и скорее всего таких доменных областей будет столько же сколько и пользователей. А голый CRUD - это самый обобщенный доступ, который можно предоставить к своим ресурсам.
Во-вторых, это общеизвестные штуки, которые не требуют доп библиотек. У REST тут чуть больше преимуществ, но в будущем думаю все же GraphQL займет лидирующую позицию, так как это полноценный язык запросов не привязанный к транспорту, а REST все же только соглашение привязанный к HTTP.

Они ограничивают Вас в низкоуровневом CRUD, создавая больше проблем, чем решают

Если не затруднит, могли бы привести пример? Кажется, речь о том, что CRUD у́же предметной области и последнюю приходится подгонять под этот самый CRUD.

Когда голый CRUD ходит между частями одного целого (например между клиентским приложением и сервером, или между двумя микросервисами), это говорит сразу о многих болячках:
1. Все разработчики вообще не знают что они делают, ни доменную область, ни решаемые проблемы, они просто бездумно пилят таски спущенные сверху, скорее всего манагером (менеджером такого назвать - язык не поворачивается), весьма далеким от разработки.
2. Между людьми, которые делают разные части системы, абсолютно нет коммуникаций, иначе они давно бы уже договорились о некоторых интерфейсах, по которым будут взаимодействовать их части, а не тратили бы уйму человекочасов на написание обобщенных интерфейсов на все случаи жизни.
3. Нет архитектора, который посмотрел бы на все это сверху и навел бы порядок, заодно сэкономив бизнесу некоторую ощутимую сумму денег.
4. Инженеров тоже нет, иначе бы давно в конторе не было копирования подходов "как у фейсбука" в бизнес похожий на ФБ как сантехник на балерину.
5. Денег тоже не особо много, во-первых зажали на архитектора и инженеров, а во-вторых, те на кого не зажали - вместо решения проблем бизнеса решают проблемы своего кода как могут, а еще иногда они выгорают и увольняются, что тоже денег бизнесу не прибавляет.
6. Код с запашком, в нем много лишнего, в нем огромное число багов, он тормозит, а его поддержка дорожает в геометрической прогрессии каждый рабочий день.
7. Скорее всего это очередной IT стартап, который загнется через некоторое время, так и не вкурив, что Цукерберг успешен не потому что бросил универ, а потому что придумал нечто новое, ну и деньги у него таки были.

Но ведь мутации в GQL +- тоже самое, что описание методов в RPC, разве нет? Можно описать метод с любым названием, отражающим суть use-case, который принимает определенный набор параметров и что-то возвращает.

Нет. При мутации в GraphQL вся бизнес логика сосредоточена в запросе, а сервер должен обработать любой такой запрос - что-то поменять у себя (ну или в 10 базах под собой, и бизнес хочет консистентно... боль...)
В RPC же вся бизнес логика инкапсулирована в коде сервера, а наружу выставляется лишь публичный интерфейс.

а так же мой любимый, но почему-то малоизвестный в русскоязычном интернете E/A/?T

Что-то ничего адекватного по запросу

rpc entity action target

не смог найти. Буду благодарен, если поделитесь ссылками на материал.

В основе лежит глава 20 из книги Роберт Мартин "Чистая архитектура", плюс статья одного блогера, которую я прочел несколько лет назад, ссылку сейчас затруднюсь дать, но идея в том, что любое взаимодействие между частями системы (в том числе сетевое) можно свести к вызову метода (Action) у экземпляра класса (Entity), а нужный экземпляр всегда можно найти по ссылке или id (Target), но Target опционален, так как бывают статичные методы. Если описать это на псевдо языке, будет что-то вроде такого:

interface Entity {
  // Action без Target
  public static ResultType action(DataType data);

  // получение Entity по Target
  public static Entity getEntity(IDType target);

  // Action с Target
  public ResultType action(DataType data);
}

[Дмитрий Беляев]

Just Me, если Вы видите только публичное API различных сервисов, которое нацелено на массовое использование и не привязано к конкретным доменам, это не значит, что другого не бывает.
RPC распространены гораздо больше чем Вы думаете, а их огромное разнообразие говорит лишь о том, что у разных бизнесов разные домены.

Яркий пример - GitHub. У него есть публичное REST API нацеленное на массового пользователя.
Но если открыть в devtools вкладку network на самом github.com, то мы увидим RPC в чистом виде

Answer 2

[Antonio Solo]

REST это вообще не "метод" а описание архитектуры. включает в себя несколько базовых принципов и все.
GraphQL напротив, это конкретный протокол взаимодействия .

а как реализовать протокол клиент-сервер надо решать исходя из конкретных условий конкретной задачи. конкретно выделенных человекочасов.

Answer 3

[galliard]

Если речь идет об одном сервисе - то нужно выбрать что-то одно. Если у тебя часть api реализовано через REST, а часть через Graphql - будет разброд и шатание.