p
Это в консерватории править, если у вас такое случается.
Потому что то же самое вам могут сделать и из rest/json-rpc
Потому что то же самое вам могут сделать и из rest/json-rpc
Size: a a a
2021 June 25
AB
Ну так если у меня http api/etc, то я и поправлю и для клиента ничего не меняется вообще. Или надо отдавать graph ql, а на бекэнде еще написать всякое чтобы эти запросы куда надо транслировались? И сколько оно будет стоить?
p
Вполне себе есть. Приходит запрос и мы из него строим граф зависимостей, а дальше исполняем паралельно.
AB
При том что на бекэенд еще микросервисы, версионирование сервисов и вот это всё?
AB
Граф мы строим понимания как всё работет. Понимания ограничения сервисов. И т.о. как раз таки "всегда нужно делать понимая, что там внутри."
p
Так никто не говорит про сложность. Да, это сложно, но оно того стоит. И сразу решается вопрос с версионированием
PD
Ну, это не дедлок все-таки.
PD
Только для bff (при чем тут rest) я просто поменяю реализацию. Кэш добавлю, например.
Более того, потребность в этом вызове станет понятна еще при разработке, при запросе на метод )
Более того, потребность в этом вызове станет понятна еще при разработке, при запросе на метод )
PD
Неа. Так как оно легко уйдет в n+1 и положит весь бэк. И graphql скорее всего так и сделает.
p
А какое дело фронту до версионирования сервисов?
PD
Это не просто сложно, это неимоверно сложно, это уровень написания распределенной базы самостоятельно.
И не дает никакого выигрыша...
И не дает никакого выигрыша...
AB
Дело вполне себе тому, кто это пишет и поддерживает на бекэнде.
PD
Это костыль, который еще и не работает (так как кэширование - не всегда разрешено).
И при этом, заметим, это одно плохое решение одной частной простой проблемы. И с этим решением мало кто справляется )
И при этом, заметим, это одно плохое решение одной частной простой проблемы. И с этим решением мало кто справляется )
AB
Классно же. Мы ушли от неудобного http rest/rpc в graphql и теперь dataloader костыли. Проблем дополнительных - масса.
AB
Вместо того чтобы написать запрос внутри апи, отдавать ответ и на этом закончить - нужно вот этим всем позниматься.
AB
Ну там даже написано. Для каждого резолвера - свой даталоадер. Т.е. нет никакой магии. Нужно писать всё это. Было сложно написать пейджинг в апишке, теперь лучше мы напишем резолверы корректные.
PD
При этом если нужна фильтрация по подтянутым данным, то все равно придется все тащить.
Так как никаких оптимизаторов в graphql нет, это же очень-очень бедное подобие sqlя, даже без хинтов.
Так как никаких оптимизаторов в graphql нет, это же очень-очень бедное подобие sqlя, даже без хинтов.
p
1. В gql разделены мутации и запросы. Так что данные очень часто можно кешить. В мутациях этот кеш, понятное дело, надо инвалидировать.
2. Если уж совсем никак, можно отдельный специфичный query написать
2. Если уж совсем никак, можно отдельный специфичный query написать
p
Версионирование. Вот у вас есть десктоп, мобилки и ещё какое-нибудь api. И вот эти все 3 вида api надо поддерживать.