PD
И как тут graphql поможет?
Size: a a a
2021 June 25
PD
При этом датамодели для бэкофиса, десктопа и API - сильно отличается )
PD
graphql - хорошее решение, когда надо быстро налабать хрень, при этом есть только фронтендер и одна база данных. Тогда можно поставить graphql поверх БД и делать классическую двузенку в стиле 90х.
Собственно, graphql - это "миллиеналы изобрели двузвенку". Ну, в конце 80х это даже казалось интересным. В конце 90х уже нет.
Собственно, graphql - это "миллиеналы изобрели двузвенку". Ну, в конце 80х это даже казалось интересным. В конце 90х уже нет.
p
Так и? Раньше это писалось в слое БЛ/хендлерах, а теперь в ресолверах.
PD
Не, без планировщика запроса в ресолвере это не сделать. А такого не предполагается, увы.
И при чем тут БЛ, это дело bff под конкретный бизнес-кейс и все.
И при чем тут БЛ, это дело bff под конкретный бизнес-кейс и все.
PD
Но фронтед сейчас и находится где-то в конце 90х, так что логично изобретение graphql.
PD
(И, кстати, в двузвенках очень быстро отказались от прямых запросов к БД и стали делать промежуточный слой из хранимых процедур. Ровно по тем же причинам, по которым лучше bff, нежели graphql)
p
О каких моделях речь, если клиент сам говорит какие поля ему нужны? Авторизация - это вообще сбоку. В ресолвере у тебя уже конкретный юзер со всеми его ролями.
Если у пользователя нет прав на получение данных, просто не отдаём их в ресолвере.
В итоге, клиент может попросить что-то что ему нельзя, но в ответе этих данных не будет
Если у пользователя нет прав на получение данных, просто не отдаём их в ресолвере.
В итоге, клиент может попросить что-то что ему нельзя, но в ответе этих данных не будет
PD
Модель - это не про поля (не только про поля), это про их связь и вообще про основной набор сущностей.
Ну и для конкретного клиента далеко не все поля доступны (мягко говоря). И далеко не все сущности.
Авторизация - это не только (и не столько) про роли, там все гораздо, гораздо сложнее, особенно для бэкофиса.
Ну и для конкретного клиента далеко не все поля доступны (мягко говоря). И далеко не все сущности.
Авторизация - это не только (и не столько) про роли, там все гораздо, гораздо сложнее, особенно для бэкофиса.
p
[frontend] <=gql=> [bff] <=> [internal services]
bff - это паттерн, который реализован в gql-сервере.
bff - это паттерн, который реализован в gql-сервере.
PD
Эээ, bff - это про "слой, который прячет сложность и готовит данные под конкретного клиента".
У тебя не может быть и gql и bff одновременно, это противоположные паттерны.
Разве что у тебя специализированные сервера gql под каждый вид клиента и его запросы.
Т.е. один apollo (c набором ресолверов, оптимизаций и т.п.) под мобилку, другой - под десктоп и т.п.
Но тогда зачем вообще gql?
У тебя не может быть и gql и bff одновременно, это противоположные паттерны.
Разве что у тебя специализированные сервера gql под каждый вид клиента и его запросы.
Т.е. один apollo (c набором ресолверов, оптимизаций и т.п.) под мобилку, другой - под десктоп и т.п.
Но тогда зачем вообще gql?
p
Почему "такого не предполагается"? Можно расставлять косты хоть на поля
p
> У тебя не может быть и gql и bff одновременно, это противоположные паттерны.
Почему?
Почему?
PD
А как эти косты работают? И ты про какую реализацию graphql сервера? И как в ней работает балансировщик?
Какие схемы джойнов поддерживаются? Работает ли с индексами? Как определяет селективность?
Какие схемы джойнов поддерживаются? Работает ли с индексами? Как определяет селективность?
PD
Я уже раза три объяснял, не?
PD
В общем случае, grapqhl - про доступ к данным независимо от клиента, bff - про автономию клиента и его bff.
Да, можно их объединять, если поднимать различное graphql api под каждого клиента и эти api будут независимыми.
Хотя мне не понятны причины для такого решения (кроме нескольких corner case)
Да, можно их объединять, если поднимать различное graphql api под каждого клиента и эти api будут независимыми.
Хотя мне не понятны причины для такого решения (кроме нескольких corner case)
RT
Хорошо сформулировал. Проблема (а иногда достоинство) GraphQL в том что прикладная логика утекает во фронт. BFF изолирует логику от фронта, превращает его в тонкий клиент, который лишь рисует отображение.
RT
У меня есть такой пример. Мобильные приложения. Всю дорогу мы боролись за то чтобы приложение было тонким клиентом и лишь отображало инструкции сервера.
В этом кейсе BFF сервис суть часть мобильного приложения, расположенная на стороне сервера.
В этом кейсе BFF сервис суть часть мобильного приложения, расположенная на стороне сервера.
RT
сервер обновлять быстро и легко, приложение обновлять долго и трудно
RT
даже если сделать релиз за один час, все равно он докатится до большинства устройств пользователей в течение порядка квартала