HATEOAS - интересная концепция - можно написать универсальный UI, который работает с разными компонентами, мы такой делали и еще я один проект видел, где по сути простой фронтенд, который умеет семантическую информацию читать и сразу вся информация и ее организация уходит в backend в данном случае. Т.е. процессы и структуру можно(мне как backend-щику так вообще за) делать на backend-е. А GraphQL - наоборот выглядит так(мне стороннему наблюдателю), будто вся логика уходит на Frontend (поэтому фронтэндщики для фронтендщиков) и соответственно, вместо универсального фронтенда получается специфичный фронтенд (заточенный под задачу или сделанный красиво), а бэкенд пусть будет универсальным, чтобы можно было и разные фронтенды писать, ничего на бэкенде не меняя.

Нет необходимости гадать, что понадобится клиентам, можно сделать по максимуму, без боязни количества трафика/запросов. Decoupling команд повышается.

Хотя я может не прав, это такой взгляд со стороны hardcore backend-щика.

Логика остаётся на бэкенде. Бизнес-правила, доступ к данным, etc. Но бэкэнд начинает меньше контролировать, что на его взгляд нужно клиентам, не надо поддерживать множество видов, в которых нужно показывать данные.

спасибо, решилось, а я в assets запихал

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

Это я и имел в виду в последнем сообщении:)

не совсем понятно насколько оно юзабельно в плане создания "моделей"

есть опыт?

Что ты имеешь в виду под «моделями»?

кстати по поводу отдать все, а потом пусть сами разбираются

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

ну если мы говорим про феникс то например схем

ы

Кеш

в графкл это же мутации как я понимаю

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

надо какие-то guards делать, чтобы прибивать такие сессии, или отправвлять их в ban

Можно отказывать запросам по complexity.

да, ребята говорили об иерархии, что можно ее ограничивать в запросах, но даже с третим уровнем можно получить проблемы((

хотя соглашусь, такая гибкость в разработке только плюс

В любом случае нужно применять голову. Если мы не ставим целью просто отдать наружу все сущности в базе, а именно делаем какое-то конкретное api то в любом случае приедется думать. Можно сразу предусмотреть и заложить в API ограничение уровня вложености и/или request rate. И мне как-то не видится реальной необходимости в очень большой вложености данных в graphql, или циклов, например. Мы же не api для обхода графов делаем, а какой-нибудь там магазинчик или порносайт в итоге...