System Design

[Afa]

вов, это домен. внешние условия, данность. от них пляшем не когда нарезаем с монолита сервис а когда делаем интеграцию с внешним сервисом. чуть другая история

[Фавн2]

друг архитечит в банке

Что используют?

[BOBA]

Ну ты Фавн спросил. По моему он дорос до того, что пишет все в Ворде, а вот до уровня когда к компу не подходят ещё нет.

Я же говорю - согласует амбиции, зоны ответственности, проблемы доступа.

Для этого используются совещания, и пишет, пишет.

А технические подробности менее важны.

Ну насколько я помню, когда уходил из ВТБ терадата как хранилище истории ещё была, уже нет, про хадуп могу уточнить, много вопросов как разложить данные бизнес сегментов раскидав на базы, и как потом сводить, базы понятно что пг. Если осенью тебе будет интересно увидеть и спросить лично? Тогда свисти. Летом не до этого. А осенью дело другое.

Ну и я не поручусь, что, работа которую работают два моих друга - архитектора будет тебе по душе.

Хотя о твоей душе я ничего не знаю.

Но, всякие технические подробности - они на втором плане, ближе к первому - понимание бизнес - процессов, и чтобы айти решения не мешали большим дядям. Как то так.

[Фавн2]

Afa, а с GraphQL не пересекался?

[Afa]

я его не люблю. это вынос на фронт/клиента решения чего хочешь получить - увеличение связности и нарушение изолированности. апи должен прописываться в доках а не в запроосе
щупал так т. сразу минус - переложить часть работы на дб становится сложнее, простые запросы но сложные сериализаторы что приводит у большей работе на апп и большей задержке ответа. не, применять наверн можно но я пока границ применимости не нащупал. предпочёл б сам проектировать апи а не сваливать на фронтов

[Фавн2]

сложные сериализаторы что приводит у большей работе на апп и большей задержке ответа

апп - это что?
Разве не должен GraphQL работать быстрее из-за уменьшения запрашиваемых данных и минимизации количества запросов к серверу?

границ применимости не нащупал

При проектировании соц.сетей GraphQL не предпочтительнее?

[Afa]

апп - приложение, сервер приложения.

когда у тебя апи вида "дай мне эту таблицу и включи в нее эти связи" - да. тогда тебе в принципе и приложение не надо, couchdb и запрашивай с неё json'ы напрямую. когда нет прямого отображения таблиц в запрос и генеришь для набегающей суммы окошечными функиям запрос с мультиджойна - ну нихрена не уменьшишь число запросов. увеличишь. к серверу бд и будешь обрабатывать их у себя в бэке. а с фронта да, ты одним запросом хапнул всё не меняя бэка. только ты того ж результата достигнешь самым обычным апи запросом, без задания на фронте что и как ты хочешь получить - у тебя в апи прописано что сервер отдаст, зачем это знание выносить в запрос? в общем, подозреваю изобрели от лени проектировать апи

подозреваю - графкуэль предпочтительней при прототипировании сайтов пляша от макета у фронта. бэк дал энтри поинт, сказал кидать туда и впихнул туда универсальный сериализатор а фронт пускай там корячится придумывает

[BOBA]

Если хочется больше свободы дать фронтовикам, и перенести на них ответственность за то, как и какие данные они потянут - им можно дать graphql как я понял...

Но это же полумера. Можно открыть им sql и дать полную свободу? В управлении желаемыми наборами данных.

[BOBA]

Была же раньше двухзвенка - толстый клиент и база. Графкьюэл кмк отчасти возвращает к этим истокам, давая на клиентскую часть больше прав и свобод?

[Afa]

вов, couchdb. принимает с фронта запрос отдаёт ответ. не взлетело. и толстые клиенты взлетают если обновления раз в год и минорны. ну попробуй для начала валидацию входных данных на бд построить. потом по правам подели возвращаемые наборы. будет весело. и пообрабатывай на фронте интеграцию с госуслугами например. от толстых клиентов и двузвенок не зря ушли. а ща даже не трех а четырехзвенка, бизнеслогику отделяют от хранилищ и показа и выделяют в отдельный слой