Size: a a a

Архитектура ИТ-решений

2020 December 02

PD

Phil Delgyado in Архитектура ИТ-решений
Yuri Gasnikov
Зато разработка фронта удешевляется в разы при хорошо спроектированной витрине, особенно , если фронтов несколько(WEb+Android+ IOS)
Ну, фронту пофиг - витрина за bff или merge. Да и на существующих платформах делать обогащение на клиенте тоже легко (если фронт говорит, что сложно - увольте их нафиг).
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну и откуда там "в разы" мне тоже не понятно. Дело точно в витрине и это точно компетентный фронт?
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
В разы вполне себе будет, если нужен "гибкий" UI с подбором колонок, разными сортировками, обилием фильтров. Merge на лету при таких требованиях на UI приводит к необходимости делать вручную соединение разных источников, разделение фильтров по ним, вплоть до выбора оптимальной последовательности фильтраций и соединений. То есть, повторяем логику оптимизатора запросов из СУБД витрины.
источник

YG

Yuri Gasnikov in Архитектура ИТ-решений
Phil Delgyado
Ну и откуда там "в разы" мне тоже не понятно. Дело точно в витрине и это точно компетентный фронт?
Ну если вы все данные берете из микросервисов, мержите и делаете пагинацию на клиенте, то в разы. Ну или в приле вы делаете слой модели, где все это реализуете, то разработка формочек проще, конечно. Только смысл эту логику реализовать на телефоне, причем на как минимум 2 разных платформах, если можно ее реализовать на витрине
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Igor Bespalchuk
В разы вполне себе будет, если нужен "гибкий" UI с подбором колонок, разными сортировками, обилием фильтров. Merge на лету при таких требованиях на UI приводит к необходимости делать вручную соединение разных источников, разделение фильтров по ним, вплоть до выбора оптимальной последовательности фильтраций и соединений. То есть, повторяем логику оптимизатора запросов из СУБД витрины.
Хм, вообще merge на клиенте при этом делается очень просто.
А "произвольные фильтры, сортировки, колонки" по разным источникам - не бывают, так оно не работает.
И даже при наличии витрины, прикрытой сверху graphql - все равно куча проблем вылезает и совокупная трудоемкость скорее возрастает, чем падает.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Ну можно на примере посмотреть. Один источник - ФИО (х10000), другой - какие-нибудь счета или заказы (x1000000). И менеджеру хочется фильтры и по сумме заказа и по части фио, и сортировки - по фио и по сумме заказа, и пейджинг. И предположим, что UI именно такой должен быть (хотя, конечно, можно долго убеждать, что UI нужно сделать более специалищированным под кейс применения). Какие варианты реализации таких выборок без витрины?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Yuri Gasnikov
Ну если вы все данные берете из микросервисов, мержите и делаете пагинацию на клиенте, то в разы. Ну или в приле вы делаете слой модели, где все это реализуете, то разработка формочек проще, конечно. Только смысл эту логику реализовать на телефоне, причем на как минимум 2 разных платформах, если можно ее реализовать на витрине
Ну, надо оптимизировать общие трудозатраты на систему.
На клиенте все равно будет модель, будет реактивное ее обновление, кэширование и вот это все
И тогда делать и локальный поиск (там, где реально) и обогащение - просто (да и само оно вылезает без проблем).
А витрину поддерживать дорого, сама витрина - очень неочевидная штука, особенно под нагрузкой и с нормальной авторизацией данных.

Да, конечно, если всех данных мало, доступов к данным нет и запросов 0.5 TPS, то можно взять любой MySQL и вперед.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Igor Bespalchuk
Ну можно на примере посмотреть. Один источник - ФИО (х10000), другой - какие-нибудь счета или заказы (x1000000). И менеджеру хочется фильтры и по сумме заказа и по части фио, и сортировки - по фио и по сумме заказа, и пейджинг. И предположим, что UI именно такой должен быть (хотя, конечно, можно долго убеждать, что UI нужно сделать более специалищированным под кейс применения). Какие варианты реализации таких выборок без витрины?
А ты можешь сказать, на какой витрине этот кейс будет нормально работать?
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
На одной общей РСУБД, в которой есть и фио, и заказы. Они ж ровно для таких задачек и придуманы.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
(Я согласен, что витрина - это дорого)
источник

AB

Alex Bespalov in Архитектура ИТ-решений
… а точно ли нужны микросервисы в этом кейсе?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Igor Bespalchuk
На одной общей РСУБД, в которой есть и фио, и заказы. Они ж ровно для таких задачек и придуманы.
Ээ, РСУБД не даст нормального поиска по части ФИО (нет там обычно приличного полнотекста, увы)
Ну и произвольные выборки на РСУБД - вещь непростая (индексы на все не прикрутишь).
Так что лучше уж делать связку CH+ES, но это уже сложный merge (
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но лучше, конечно, изменить требования, оно в разы дешевле.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Alex Bespalov
… а точно ли нужны микросервисы в этом кейсе?
Я не говорю, что они нужны. Я говорю, что имея распределенную архитектуру по типу микросервисной, вы можете попасть на такую задачу. И есть разные варианты ее решения, начиная с отказа ее решать, и заканчивая витриной.
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
Phil Delgyado
Ээ, РСУБД не даст нормального поиска по части ФИО (нет там обычно приличного полнотекста, увы)
Ну и произвольные выборки на РСУБД - вещь непростая (индексы на все не прикрутишь).
Так что лучше уж делать связку CH+ES, но это уже сложный merge (
Ну, обычно людям конечно нужен поиск по началу фамилии. Это норм индексируется. А CH - это что ты имеешь в виду?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Igor Bespalchuk
Ну, обычно людям конечно нужен поиск по началу фамилии. Это норм индексируется. А CH - это что ты имеешь в виду?
Ну, обычно нужно просто вбить что-то и получить )
CH - ClickHouse
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Хотя надо на кейсы смотреть, конечно (
источник

SB

Sergey Bezrukov in Архитектура ИТ-решений
Phil Delgyado
Но лучше, конечно, изменить требования, оно в разы дешевле.
Ага. А то ишь кожаные мешки разбаловались, поиск по нескольким критериям им подавай )  
Самая жестяная жесть, это когда ФИО, например, в какой-нибудь отдельной БД thanks to 152-ФЗ и в витрину их по той же причине фиг вытащишь.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, ФИО почти всегда нужно шифровать, да.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Вообще, как ни грустно, нормальных инструментов для витрин сейчас нет.
источник