В graphql тоже самое, как ты написал хэндлер, так и будет

если graphql рассматривать, как стандарт протокола - то да. Если его рассматривать в реальном мире, с точки зрения реализации на конкретной базе - то это вырвиглазная наркомания

Давай в примере, опиши рест, а я опишу спеку )

что в примере?

приведи пример бизнес-логики

я тебе объясню, почему там не нужен graphql

На твой выбор

не, ну ты же утверждаешь, что он нужен :) вот и приведи пример, где без него никак

Я не говорю, что без него никак. Я говорю с ним можно жить

не, ну ты же утверждаешь, что он нужен :) вот и приведи пример, где без него никак

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

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

значит, надо различать клиенты на бэкенде, например, используя разные токены авторизации. Причем тут graphql?

Я не говорю, что без него никак. Я говорю с ним можно жить

но без него лучше :)

значит, надо различать клиенты на бэкенде, например, используя разные токены авторизации. Причем тут graphql?

А можно просто использовать GraphQL

значит, надо различать клиенты на бэкенде, например, используя разные токены авторизации. Причем тут graphql?

У тебя могут быть разные версии клиентов, у одних инфо больше у других меньше

А можно просто использовать GraphQL

зачем? нет логики, "у меня два клиента - давайте-ка я в разы усложню бэк"

но без него лучше :)

Давай проще. Магазин. Клиент и его покупки. Реализуй рестом

У тебя могут быть разные версии клиентов, у одних инфо больше у других меньше

это "версионирование API" называется

зачем? нет логики, "у меня два клиента - давайте-ка я в разы усложню бэк"

Да не усложнишь ты ничего

если кратко, то это допустим ты получаешь дату, но тебе нужно ее конвертировать, ты создаешь мутатор который возвращает уже отформатированную жату если не ошибаюсь

Изменение данных

зачем? нет логики, "у меня два клиента - давайте-ка я в разы усложню бэк"

Почему усложню то?

Да не усложнишь ты ничего

разумеется, усложню. Ты какими-то абстрактными терминами мыслишь. Вот у тебя база, вот у тебя логика. Для GraphQL надо написать уйму кода, который будет маппить одно на другое. Для REST-нет

если кратко, то это допустим ты получаешь дату, но тебе нужно ее конвертировать, ты создаешь мутатор который возвращает уже отформатированную жату если не ошибаюсь

Нет, эт лучше через квери делать

разумеется, усложню. Ты какими-то абстрактными терминами мыслишь. Вот у тебя база, вот у тебя логика. Для GraphQL надо написать уйму кода, который будет маппить одно на другое. Для REST-нет

Да нет ж. Открой код какой нибудь сангрии

Нет, эт лучше через квери делать

я написал вообщем, я не имею ввиду graphql, мне он не нужен )

@Enchantner я примерно так же скандалил когда впервые услышал про NoSQL

Да нет ж. Открой код какой нибудь сангрии

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

вон github начал юзать graphql, ну так открытое же апи

Мутации нужны чтобы менять данные, это ж мутации. ))) условно говоря пост в тесте

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

Не будет

Не будет

разумеется, будут, не смеши

разумеется, будут, не смеши

Нет не будет

Вообще никаких

Нет не будет

нет ты

да дохера будет

как минимум потому что джойны устроены категорически иначе, а ORM общего для них нет и быть не может вменяемого в принципе

это тупо другая база абсолютно с другой логикой работы с ней

`{ user(id: "ZW5jaG9kZSBIZWxsb1dvcmxk") { id name friendsConnection(first: 3) { edges { cursor node { id name } } } } }` я думаю это еще цветочки с вложенностью )

Это будут изменения в dao слое

чтобы фронту было удобнее рендерить хрень, давайте сделаем плохо бэку

Доменная область останется также

это ущербная логика

Да ничего там не плохо)))?

`{ user(id: "ZW5jaG9kZSBIZWxsb1dvcmxk") { id name friendsConnection(first: 3) { edges { cursor node { id name } } } } }` я думаю это еще цветочки с вложенностью )

+++

`{ user(id: "ZW5jaG9kZSBIZWxsb1dvcmxk") { id name friendsConnection(first: 3) { edges { cursor node { id name } } } } }` я думаю это еще цветочки с вложенностью )

Да, у нас максимум стоит 10

скажите, зачем тогда уж http code ? как будут ошибки выдаватсья ? эт интересно

у меня был один раз чувак, который ныл, чтобы ему в JSON поля отдавали CamelCase'ом, ибо у него иначе линтер на фронте ругался. Он призывал отменить pep8 и названия полям в модели дать таким образом.

скажите, зачем тогда уж http code ? как будут ошибки выдаватсья ? эт интересно

Там есть поле errors

у меня был один раз чувак, который ныл, чтобы ему в JSON поля отдавали CamelCase'ом, ибо у него иначе линтер на фронте ругался. Он призывал отменить pep8 и названия полям в модели дать таким образом.

???

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

???

Тоже было такое )))))))))))

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

`{ user(id: "ZW5jaG9kZSBIZWxsb1dvcmxk") { id name friendsConnection(first: 3) { edges { cursor node { id name } } } } }` я думаю это еще цветочки с вложенностью )

Это кстати всего 2 запроса в базу

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

Точно не понимаешь

Точно не понимаешь

или ты

Да у меня хотя бы есть приложения на graphql

И я понимаю для чего он

ну вот я тоже понимаю, для чего он. Крайне узкая и специфическая сфера, и то не факт, что там без него не было бы лучше

по сути, такие технологии появляются, когда фронтенд и бэкенд категорически хреново взаимодействуют по теме бизнес-логики

Да все там отлично с этим

Кстати ещё и на микросервисы ложиться не плохо

Кстати ещё и на микросервисы ложиться не плохо

каждый день ложусь на микросервисы, ага

нет, хреново он ложится на микросервисы, разумеется

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

API с джойнами и сложной логикой сюда никак не вписывается

ERROR: S client not available

Если у тебя есть сервис, который берет кучу данных от кучи микросервисов, то graphql отлично ложится на микросервисы

Если у тебя есть сервис, который берет кучу данных от кучи микросервисов, то graphql отлично ложится на микросервисы

куча данных от других микросервисов оверхед на TTFB как минимум с каждого сервиса допустим +30ms + еще на graphql 40ms не знаю сколько там отдается и как работает graphql

Если у тебя есть сервис, который берет кучу данных от кучи микросервисов, то graphql отлично ложится на микросервисы

если у тебя есть сервис, который берет данные от кучи микросервисов, да так, что тебе нужны джойны данных для этого - то ты ССЗБ

тут дело не в graphql, а в прокладке между стулом и монитором

Джойны данных иногда нужны, но страшного в этом обычно ничего нет

Джойны данных иногда нужны, но страшного в этом обычно ничего нет

они часто нужны. Только фронт к ним отношения никакого иметь не должен.

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

они часто нужны. Только фронт к ним отношения никакого иметь не должен.

согласен

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

если без базы да, но куда в наше время без базы ?

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

правильно, зачем нам база в распределенной бизнес-логике

еще б впихнуть 1 базу для всех сервисов ))))

Баз в распределенной бизнес логике куча :) но они в этом случае делаются достаточно простые, и запросы туда тоже простые

вот как ни как, лично с graphql понравился бы join с нескольких сервисов с баз но настораживает э онли бизнеслогика на бекенде

Ну у нас это работает. Куча сервисов через grpc общаются, и затем в graphql пихается и все быстро и хорошо работает.

Баз в распределенной бизнес логике куча :) но они в этом случае делаются достаточно простые, и запросы туда тоже простые

вот и не надо фронт туда еще приплетать)

А при чем тут фронт?

Ну у нас это работает. Куча сервисов через grpc общаются, и затем в graphql пихается и все быстро и хорошо работает.

"у нас работает" - это не аргумент :)

Фронт оперирует только данными. И запрашивает что ему нужно

у кого-то и гомеопатия работает

А какой аргумент надо? Я же говорю исходя из практического опыта :)

Фронт оперирует только данными. И запрашивает что ему нужно

есть протокол взаимодействия фронта с бэком. Есть эндпойнты и варианты запросов к ним по HTTP

фронт не должен хотеть ничего за пределами этого протокола, как и бэк не должен отдавать

Ага, graphql-схема. В которой описаны все запросы и типы данных

Что не так?)

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

Что не так?)

а она не нужна :) есть просто схема, graphql там ни при чем

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

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

все так

Ну можно json-rpc сделать. Только принципиальная разница то какая? :)

Ну можно json-rpc сделать. Только принципиальная разница то какая? :)

можно вообще все в один хэндлер запихать и делать на него POST, да. Только надо от логики исходить всегда