A
ну да, сразу в прод
Size: a a a
2021 June 25
p
Окей, а как сделать "вот пользователь, нужные последние 5 заказов с историей изменения статуса по каждому заказу"?
p
А на другом конце хрупкий монолит, который не умеет в graceful degradation и мемлик в котором приводит к бедам у всего сервиса
PD
На bff - делать запрос под задачу. И разбираться с тем ,как его реализовывать, так как все очень сильно зависит от бизнес-сценария (иногда спасет кэширование, иногда под такие задачи вообще нужно много что перетряхивать)
АП
Ну часть этих проблем может быть не актуальна (например, распределённые транзакции)
Что такое сквозной рефакторинг?
Что такое сквозной рефакторинг?
PD
Э, так graphql - это и есть "монолит из микросервисов". С ровно теми же проблемами (
p
И плодить методы, которые возвращают то же самое, но чуть-чуть другое с другим набором полей.
A
судя по документации в github - никаких, это как спринг или как ratpack
PD
Ну, распределенные транзакции нужны, на самом деле, всегда. Просто иногда на них плюют.
Сквозной рефакторинг - это про рефакторинг по всему продукту, по всем сервисам.
Сквозной рефакторинг - это про рефакторинг по всему продукту, по всем сервисам.
PD
Да там у них на сайте вообще явное вранью. Fault toleranсe у них - это про retry, оказывается )
PD
Нет, плодить методы под бизнес-задачи.
И думать, да.
И думать, да.
AB
А как быть с тем, что я отдал graph_ql мобильным клиентам, они там наделали запросов и теперь у меня дедлоки? Что сказать dba? Ща на конкретный graph-ql запрос прибьет конкретный запрос в БД на стороне апи обслуживающего graph ql запросы?
АП
Так разве сквозной рефакторинг связан с монолитом/микросервисами? Это скорее к тому как код хранится
A
и чтобы починить надо выпустить новую версию мобилки и обновить всех пользователей
AB
да, пусть все обновляются принудительно. не понимают что ли, что у нас важный апдейт
PD
Для задачи "вот пользователь, нужные последние 5 заказов с историей изменения статуса по каждому заказу" вообще нет нормального универсального решения в распределенной среде. Ее всегда нужно делать понимая, что там внутри.
PD
О, еще как связан, так как нужно следить за совместимостью API между разными версиями сервисов.
Если в монолите нужно следить только за публичным API всего контекста (даже при выкладке без простоя), то в микросервисной архитектуре нужно отслеживать версионирование и внутренних вызовов.
Если в монолите нужно следить только за публичным API всего контекста (даже при выкладке без простоя), то в микросервисной архитектуре нужно отслеживать версионирование и внутренних вызовов.
PD
Ну, будем честными, graphql только про select, он не может приводить к дедлокам.
Но к медленным запросам и деградации общей производительности - легко
Но к медленным запросам и деградации общей производительности - легко
PD
graphql можно заставить работать на конкретной системе - написав с нуля весьма нетривиальный сервер для его реализации, с сложной специфичной логикой запросов. Но это дорого и недоступно большинству разработчиков (это примерно как писать аэроспайк с нуля)
AB
ну, формально, бывают истории с тем, что при селект параллельно где то был апдейт и жертвой пал селект