PT
Супер.
Size: a a a
2020 December 02
PT
Какие инструменты для этого есть?
PT
Что можете посоветовать?
YG
Что можете посоветовать?
Надо смотреть по проектной производительности- что потянет движок БД витрины, если нет прям жесткого HighLoad , то я бы взял что нибудь из SQL ( удобнее разрабатывать). По готовым инструментам сборки витрины не подскажу - не копал вопрос глубоко
YG
Сам сейчас нахожусь в вялотекущем выборе архитектуры такого решения( непонятно- стартует проект , или нет)
LV
Yuri Gasnikov
Я бы делал витрину данных с локальным хранилищем. Подозреваю , что помимо пагинации, данные из разных микросервисов надо мержить. Это + пагинация делает формирование ответа на лету монструозным и неповоротливым
+1.
LV
Если у вас прям микросервисы, то можно так. Все сервисы с первичными данными шлют нотификации об изменившихся объектах (через distributed log или message broker). Все витрины подписываются на нужные изменения и обновляют свои данные.
LV
Одна витрина или не несколько. Тут общии критерии у меня такие:
* витрина под клиента - это первое и прям классика, как я понимаю
* у одного клиента может быть несколько разных витрин. Например, одна поисковая, другая аналитическая.
* витрина под клиента - это первое и прям классика, как я понимаю
* у одного клиента может быть несколько разных витрин. Например, одна поисковая, другая аналитическая.
LV
Конкретное решение, конечно, надо смотреть по задаче
SB
Roman
кваркус известен всем, да. но опять же по возможностям до спринга как до луны
Это ошибочное мнение.
И что известен всем, и про луну.
И что известен всем, и про луну.
A
Yuri Gasnikov
Это , по крайней мере , логично
Получается типа отдельный "микросервис" для фронта?
PD
Всем привет. Есть вопрос к сообществу.
Задача: есть микросервис, в котором есть товары.
Сущность товара состоит из: id, цена, название, картинка.
Есть микросервис биллинга, в котором есть транзакции.
Транзакция - id, дата транзакции, id пользователя, id товара.
Нужно запилить фронт, на котором будет показываться список транзакций сразу с инфой по товарам. Например, в элементе списка будет дата транзакции, имя и фотка товара.
Проблема - данные берутся из разных микросервисов.
Первый вариант, который приходит в голову - запилить backend for frontend, который будет собирать сначала транзакции, а потом списки товаров и уже готовый json отдавать на фронт.
Но проблема - что если понадобится что-то более сложное? Может быть сразу с пагинацией и фильтрацией.
Какие еще варианты есть?
Задача: есть микросервис, в котором есть товары.
Сущность товара состоит из: id, цена, название, картинка.
Есть микросервис биллинга, в котором есть транзакции.
Транзакция - id, дата транзакции, id пользователя, id товара.
Нужно запилить фронт, на котором будет показываться список транзакций сразу с инфой по товарам. Например, в элементе списка будет дата транзакции, имя и фотка товара.
Проблема - данные берутся из разных микросервисов.
Первый вариант, который приходит в голову - запилить backend for frontend, который будет собирать сначала транзакции, а потом списки товаров и уже готовый json отдавать на фронт.
Но проблема - что если понадобится что-то более сложное? Может быть сразу с пагинацией и фильтрацией.
Какие еще варианты есть?
Все зависит от нагрузки и профиля.
Если по требованиям нормально работает merge (на bff или клиенте - это тоже могут быть разные варианты), то проще оставить merge.
Если не высокая нагрузка, то получить список транзакций, а по ним вытащить списком те товары, которых еще нет в кэше - достаточно быстро.
Если нужны сложные фильтрации по связанным данным (история по имени товара, но отсортированная по дате), то не обойтись без витрины данных, оптимизированной под задачи поиска (PG/ClickHouse/ElasticSearch etc)
Если по требованиям нормально работает merge (на bff или клиенте - это тоже могут быть разные варианты), то проще оставить merge.
Если не высокая нагрузка, то получить список транзакций, а по ним вытащить списком те товары, которых еще нет в кэше - достаточно быстро.
Если нужны сложные фильтрации по связанным данным (история по имени товара, но отсортированная по дате), то не обойтись без витрины данных, оптимизированной под задачи поиска (PG/ClickHouse/ElasticSearch etc)
PD
Но корректная поддержка витрин - это дорогая и противная штука, которую нужно делать если нет иного выхода.
Так как надо следить за ее целостностью, помнить про нее при изменениях в данных заполняющих сервисов и т.п.
Так как надо следить за ее целостностью, помнить про нее при изменениях в данных заполняющих сервисов и т.п.
PT
Спасибо за советы. Буду прикидывать, как что сделать.
PD
Я в свое время писал для разработчиков "чеклист-алгоритм" про то, как делать выборки
(на клиенте, на bff, на витрине или нужен ADR)
(на клиенте, на bff, на витрине или нужен ADR)
VA
Я в свое время писал для разработчиков "чеклист-алгоритм" про то, как делать выборки
(на клиенте, на bff, на витрине или нужен ADR)
(на клиенте, на bff, на витрине или нужен ADR)
ADR?
PD
Требуется решение от архитектора (Architecture decision record)
VA
Тогда понятно) Я предположил что это что-то ещё))
PD
Ну, в чеклисте очень часто полезно выделять путь "а тут надо бы подумать".
YG
Но корректная поддержка витрин - это дорогая и противная штука, которую нужно делать если нет иного выхода.
Так как надо следить за ее целостностью, помнить про нее при изменениях в данных заполняющих сервисов и т.п.
Так как надо следить за ее целостностью, помнить про нее при изменениях в данных заполняющих сервисов и т.п.
Зато разработка фронта удешевляется в разы при хорошо спроектированной витрине, особенно , если фронтов несколько(WEb+Android+ IOS)