Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Вопросы к эволюции или почему REST стал везде доминировать

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем Привет, В двух темах по REST я неоднократно высказывал свое мнение, что REST как и любой RPC, не является хорошей зрелой технологией для получения\синхронизации данных. Там мы частично обсуждали темы про GraphQL и Service Bus, которые являются более зрелыми технологии для обеспечения внутресетевых коммуникаций между программным кодом. Там меня просили оформить свои мысли в отдельную тему. В какой-то момент, я хотел скопировать банальный длинный список приимуществ со своих преведущих сообщений в других темах, но потом подумал, что всеже мы упускаем суть.

Пинать RPC (и его современное подобие в лице REST) не будет только ленивый. Он зарождался в 50е годы на мейнфреймах, как только между компьютерами появилось сетевое взаимодействие. И первая мысль конечно была, "о ребята, а давайте теперь дергать методы у компонент так, как будто они у нас на одной машине"©. Ну на одной машине и на одной машине, про латенси, ретрай, консистенси, бродкастинг, маршалинг, горизонтальное масштабирование, изменчивость контрактов и версионность, профилирование и многие другие проблемы, которые совершенно внезапно возникают когда ваши компоненты больше не живут в одном адрессном пространстве процесса, тогда конечно никто не думал. Так и повелось.

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

И я скопирую свой пост из соседней темы:

Предоположим у нас есть 100 тыс клиентов базы данных, которые запускают тяжелые запросы по центральной базе данных, на основе какого-то SELECT ... FROM ... WHERE. Причем этот SELECT ... FROM ... WHERE у каждого клиента свой, индивидуальный.
Можно ли центральную базу данных написать так, чтобы клиенты вместо того, чтобы каждый раз дергать SELECT ... FROM ... WHERE на базе, просто подписывались (subscription) на изменения данных и сервер просто досылал новые данные которые подпадают под запрос клиента. Причем сервер не выполняет (!) запрос заново, он идет по более короткому пути, анализируя изменения на таблицах и может обрабатывать сотни тысяч подписчиков одновременно.
Соответственно клиенты сервера не только не выполняют SELECT ... FROM ... WHERE на каждый рефреш они еще и получают данные асинхронно, как только они изменились на сервере.

Задача не такая простая как кажется, поскольку данные на которых базируется WHERE тоже могут менятся. А значит клиенту могут прилетать не только единичные инсерты или апдейты как в обычной подписке, но и балковые апдейты, типа удалить все, залить вот это все по новой.

Сейчас я понимаю что такой механизм построить реально. Это полностью инвертирует понимание, _как_ может строится взаимодействие между клиентом и сервером.

Воощем как говорил когдато Булгаков устами Воланда.
"Люди как люди, такие же как и были, просто их испортил квартирный вопрос"©
Можно перефразировать на программирование. Программирование как программирование, такое же как и было, синхронизация данных испортило современное программирование.
Возможно удасться это починить.

Итак, какие же проблемы здесь решены. Их всего три:

  • Сервер координально разгружен от выполнения однотипных запросов. Клиенты могут использовать свою закешированную подножную локальную субд, которая и меньше по размерам и на порядки быстрее работает.
  • Сервер управляет консистентностью данных своих клиентов. На самом деле это неочевидно, но любая распределенная система постоянно борется со своей консистентностью. Распределенные системы должни строиться по принципам восстановления данных, а не копирования чего-то куда-то без анализа с какой версией мы работаем и сколько мы были в офлайне. Как это делает любой RPC колл.
  • Клиент получает данные асинхронно. Это риалтайм обновление данных.

Тоесть, если посмотрить в суть, на самом деле, системы должни решать проблему синхронизации данных между собой, а не дерганья методов у друг друга. Это меняет понимание того, как можно строить сложные, гибкие и консистентые системы.

Дискасс ?

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Эволюция синхронизации данных.
Откуда и куда идём.

Синхронизация для самых маленьких
1. Клиент ничего не кеширует, на каждый чих задергивает сервер

Синхронизация для начинающих
2. Клиент кеширует данные, но каждый раз перед стартом чистит кеш и грузит с сервера все по новой.

Синхронизация для любителей
3. Клиент кеширует данные, но каждый раз перед стартом кеш не чистится, а получает дифф последних изменений с сервера. При поломке данных возможен хелзчек и восстановление данных

Синхронизация для профессионалов
4. Клиент кеширует данные и может работать с ними в офлайне. При выходе в сеть сервер умеет правильно мержить истории изменений от разных клиентов. Резолвит конфликты.

Вот дочитываю Кабанчика. Дословно:

Traditionally, web browsers have been stateless clients that can only do useful things
when you have an internet connection (just about the only thing you could do offline
was to scroll up and down in a page that you had previously loaded while online).
However, recent „single-page” JavaScript web apps have gained a lot of stateful capa‐
bilities, including client-side user interface interaction and persistent local storage in
the web browser. Mobile apps can similarly store a lot of state on the device and don’t
require a round-trip to the server for most user interactions.

These changing capabilities have led to a renewed interest in offline-first applications
that do as much as possible using a local database on the same device, without requir‐
ing an internet connection, and sync with remote servers in the background when a
network connection is available [42]. Since mobile devices often have slow and unre‐
liable cellular internet connections, it’s a big advantage for users if their user interface
does not have to wait for synchronous network requests, and if apps mostly work off‐
line (see „Clients with offline operation” on page 170).

When we move away from the assumption of stateless clients talking to a central
database and toward state that is maintained on end-user devices, a world of new
opportunities opens up. In particular, we can think of the on-device state as a cache of
state on the server. The pixels on the screen are a materialized view onto model
objects in the client app; the model objects are a local replica of state in a remote
datacenter [27].

Пять лет прошло. И где?
Идея, значит, не новая, и настолько же живучая и полезная, как умный дом.

Згідний, про що тут говорити.

Коли WebAssembly зіллється з JVM, настане сингулярна прозорість.

Говоря рест вы имеете ввиду именно HTTP API или же имплементация принципов RESTfull, написанных в 90х по средствам HTTP API ?

В сабже основная мысль что RPC как технология (любая из них, rest, WCF, grpc, DCOM, sb и тд) достаточно низкоуровневая чтобы с ней возится в своем прикладном программном коде.
Причем идея синхронизации и интеграции данных намного шире чем может показаться на первый взгляд. Любое дублирование данных, будь то в кешах или денормализация данных, представление в виде вью, прокси подгрузка, уже попадает под принципы синхронизации данных, даже если эти данные находятся на одной машине.

Ну надо было сразу рекомендовать почитать Designing Data-Intensive Applications.
Но суть в том, что если у тебя молоток — то все будет гвоздями.

Но суть в том, что если у тебя молоток — то все будет гвоздями.

В 2050 будут говорить не так. Если у тебя в руках 3д принтер, все вокруг будет казаться бумагой для распечатки =)

Да я о себе тоже.
В эмбедеде акторы — средство работы с control flow. А в бекенде — с data flow. То есть — это уже pipes and filters, а не набор state machines, реализующих дерево решений для передачи сигнала.
Вот я долго не мог понять, нафиг тащить акторов в бекенд, когда от них столько проблем. Оказалось — в бекенд затащили pipes and filters, но назвали их акторами.
Вот для меня все есть сигналом, а для разработчика БД все есть репликацией.

Вот для меня все есть сигналом, а для разработчика БД все есть репликацией.

Сигнал это частный случай репликации.
Можно представить это как отправка письма получателю. С точки зрения сигнала или удаленного кола RPC, данные просто отправляются как единичное письмо получателю. Не обрабатывается ситуация что получатель может быть какое-то время не доступен. Не обрабатывается что письма можно доставить пачкой, включая соседей. Не обрабатывается что письмо уже устарело и нужно перепаковать письмо. Получатель сменил место жительства и другое.

Пример из жизни. Видим объект на картинке.

Сигнал (control flow):
Распознаем объект. Если это кошечка — запускаем последовательность событий (сценарий) подойти погладить. Если это собака — добавляем отслеживание расстояния с нотификацией на сценарий пинка если расстояние станет меньше заданного. Если это ворона — размораживаем актор рогатки и начинаем итеративное уменьшение погрешности прицеливания.
То есть, у нас одна картинка может вызвать сотню разных результатов. И вряд ли кто-то решится это все описывать как вьюшки на набор пикселей. И одновременно будет существовать только один или два результата (вьюшки) — остальные не нужны, потому что сценарий или вьюшка, который используется, как раз зависит от логики обработки картинки и текущего состояния фильтров, выше стоящих в дереве решений. Это control flow. Нам не нужна рогатка, когда видим сестру.

Поток (data flow):
Выгребаем пиксели с матрицы, применяем коррекцию известных горячих и холодных пикселей, применяем шумоподавитель с заданным порогом, применяем коррекцию яркости и цветовой гаммы, переводим в RGB, ужимаем в JPEG, сбрасываем на накопитель.
Это data flow. В нем почти нет условных ветвлений, граф потока данных однажды создан, заморожен, и не меняется в штатных ситуациях.

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

Репликация подразумевает реплику. Тоесть мы реплицируем определенный срез одинаковых данных учитывая фильтр, секурити, валидацию, овнера и другие параметры. То о чем ты говоришь, это уже чистая бизнесс (не аспектная) логика. Обычно она навешивается как триггер или скрипты поверх данных, которые прилетели к нам из вне.

Зависимость table->materialized_view это ведь тоже репликация с трансформацией, вроде.

Да, я говорю о бизнес логике. И о том, что есть 2 мира: мир событий и мир данных. И у них пересекается терминология, и они путаются в головах.
Даже в телефонии есть отдельные control plane и data plane, они обычно бегут по разным сокетам и обрабатываются разным кодом.

Чем то отдаленно напоминает Meteor и Logux.

Тут один намедни мне сказал, что у меня алгоритм нахождения центра какой-нибудь цветовой области хорош несказанно. Это как-то связано с проблематикой — монолит против микросервисов?

А как на клиенте (браузере) заюзать GPU для вычислений? А то вроде компьютеры стали быстрыми, но все тормозит, пробовали просто интернет посерфить на 2-х ядерном процессоре (до 2008 их вообще в пользовательском сегменте не было)?

в мире Бубена нет вычислений, есть только данные))

Кстате интересный вопрос. Вот взял ради интереса свой рабочий проект на шарпе и запустил поиск найти все ++. Инкремент используется широко в вычислительных задачах. На литкод наверно 9 из 10 задач требует инкремент. И что я вижу всего 160 вхождений. Делаю поиск по public оператор, даже не private. 17538 вхождений. Получается эта вундервафля на пол миллиона строк все что делает трансформирует и гоняет туда сюда данные.

Кто не уверен в операторе ++ для Шарпа, форич итераторы и всетакое. Сделал поиск по операторам <= и >= . В обоих случаях в районе 50 вхождений. Это смешно, но серьезная тула которая занимается аналитикой имеет формул на один эксель лист. И такое в индустрии сплошь и рядом. 99% баласта в коде

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

Посчитать ту же нейронку, дообучить её на текущих данных от клиента и передать изменения на сервер. Да к примеру распознавание голоса или частичное распознавание голоса делать на клиенте, а не грузить сервер. Ну или к примеру запросы принимать не на SQL, а на natural language и обрабатывать через NLP.

Так ML это другая тема. Это кубик в пайплайне. Он может принимать какие-то данные и отправлять, но сами данные за него считать никто не будет. Грубо говоря если ML это пассажир, то я строю всего лишь самолёт который молча его будет возить туда ообратно и ему не придется добираться всякими рест автостопами через пол страны, заполняя кучу бумажек или голосуя на дороге

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

Нынче проще месить ангуляр или накидывать компоненты в реакте за больший рейт и не страдать фигней =)

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

Что-то подобное было в свое время с knockout.js, офигенно работает как демка и намертво кладет браузер, когда надо хотя бы 100 элементов в таблице отобразить.

Challenge accepted.
Благо не знаю как в вашем 2021, но в 2050 году, чтобы запилить форму на 200 контролов, с пейджингом, синхронизацией с центральной бд, фильтрацией и редактированием нужно .... эммм.... минуты 2 ?

gifyu.com/image/S2CmS

Ничего не тормозит. Все отрисовывается мгновенно. Открытие и сохранение формы на 200 контролов занимает миллисекунды. Пейджинг и фильтрация контролов прикручивается в два клика. Настраивается пейджинг в один клик.

ЧЯДНТ ? Артем, ты действительно думал, что у создателя базы днипро ди би, которая молотила по 3млн апдейтов атрибутов за секунду в документах, может хоть что-то тормозить. По крайней мере в таких глупых задачах, как показать круд форму на 200 контролов, редактировать ее пейджировать и фильтровать. :D
Каменный век.

В топик призывается подполковник Бугай с его духовным наставником Моренетс !
Пускай теперь расскажут, сколько стоит запилить форму на 200 контролов, забайндить ее с центральной базой данных, за секунды прикрутить туда пейджинг, фильтрацию, взрослое секурити, валидацию, кеширование, визард .. имя им легион.

А теперь заставь ее тормозить. И всем все сразу станет ясно.

В первых версиях придется добавить какой-то Thread.Sleep(3000). А то у всякой ноджс и джава флоры рухнет хрустальный мир и они с словами «Бл* а чо так можно было ??!» начнут жёстко прибухивать. Мы не можем их потерять ! Иначе ИТ индустрия развалится наступит временной коллапс и я не смогу существовать тут из будущего. Парадокс времени и всетакое.

Поменьше времени всматривайся в червоточины, понимай, что они существуют, появляются в донорно акцепторных конкатенациях нейронов, и приносят целую кучу информации, не привязанной к текущим реалиям бытия то есть контекстам. «вырвано из контекста» это про информацию из червоточины. Это самая поганая форма информации.
Это идеи, мечты, желания, сиюминутные мотивации и т.п.
Только записанному можно верить. А еще лучше записанному и не раз уже прочитанному и пару раз протестированному. Десятков раз.
Вот только это невозможно, а так все в порядке.
Информация из червоточины, информация неопределенная, информация вне контекста это все об одном и том же.
И конечно это же и есть информация из некоторого весьма вероятного будущего исходя из текущих реалий.
Но что если текущий реалии изменятся? Изменится тогда и неопределенная информация. Вот в чем фокус!
И под конец — вишенка на торте:
А что если неопределенная информация (из будущего) будет ошибочно взята во внимание и именно в силу этого изменятся текущие реалии?
Я тебе изложил основы паралогики, потому что ты себя экспертом назвал.
P.S.
Неужели тебе так хочется покататься на Делориан?

И не говори. Глупцы ! Вокруг нас миллион подсказок, от микро до макро мира. Просто скопируйте и вставьте это в свой факин код. Почему у пчелы с несчастной тысячей нейронов работает распознавание лиц, карт, и даже тягает предметы на столе решая логические задачи, общается. А ваш факин код исчесляется гигабайтами и едва ворочает несчастные круды. Опомнитесь. Все, расстраиваете вы меня, пойду помечтаю о 2050 годе, где уже все хорошо )

Там есть криптовалюты? Почем Солана ?

Солана в 2050 году всё. Но успеешь ли ты что-то на ней заработать до 2050, неизвестно.

Мде. Ведь многие говорили что она и аваланш придут на смену всем этим биткоинам и эфириумам. Что же произошло, что такие быстрые транзакции в мире вечных записей никому вдруг не подошли?
А! Квантовые оптические компьютеры... или оптические квантовые...

В 2035 году был построен первый массовый квантовый компьютер на кубитах общего назначения, который был примерно в 1 млн мощнее современной персоналки и в 5 млн раз мощнее в пиковых нагрузках.
К сожалению его оказалось недостаточно чтобы ворочать круды на джаве. Компания которая его производила — разорилась.

Да,да, пустыня из песчинок складывается. А сами песчинки из горных вершин.

Challenge accepted.

Как человеку, которому плевать на мое мнение, ты слишком много усилий тратишь, чтоб решить мои челенджи.

Ничего не тормозит. Все отрисовывается мгновенно.

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

Каменный век.

Я не могу ничего по твоему сжатому видео разобрать. Это Windows Forms? В 2021 году пилить такое — действительно каменный век.

Это Windows Forms? В 2021 году пилить такое — действительно каменный век.

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

Это Windows Forms? В 2021 году пилить такое — действительно каменный век.

А на чем пилить десктоп под винду, чтобы это было не каменный век?

Я разбираюсь, позже отпишу возможно.
Но сходу, почему винформс как обертка над винапи «фуу, легаси, каменный век», а растовая обертка над винапи это «кул, эмэйзинг»?
github.com/...​abdube/native-windows-gui

Не могу найти сходу промышленную библиотеку растовых контролов под винду.
Нашел ссылку www.areweguiyet.com

Это был сарказм если что. Раст замена C++, юаи на нем не особо

Но сходу, почему винформс как обертка над винапи «фуу, легаси, каменный век», а растовая обертка над винапи это «кул, эмэйзинг»?
github.com/...​abdube/native-windows-gui

Эскобар.джпг

Писать напрямую через WinAPI, или через Windows Forms, или через WPF — это вендор лок ин под винду. В 1995 году это было нормально.

Не могу найти сходу промышленную библиотеку растовых контролов под винду.
Нашел ссылку www.areweguiyet.com

С UI еще не все так хорошо как хотелось бы в расте, но вы держитесь.

Писать напрямую через WinAPI, или через Windows Forms, или через WPF — это вендор лок ин под винду. В 1995 году это было нормально.

Вообще-то вверху .NET. Он на раз два портируется под тот же Моно и запускается на Линукс. Не похоже на 1995 год

Если винформс умерли, почему майкрософт изо всех сил пытается в .net 5 дать возможность разрабатывать на винформах?

Я хз зачем. Лучше бы они запилили кросс-платформенный UI фреймворк под .net core.

Как человеку, которому плевать на мое мнение, ты слишком много усилий тратишь, чтоб решить мои челенджи.
эммм.... минуты 2 ?

youtu.be/jg-6gIUu3j4

Распространение REST происходит в следствие распространения Single Page Application и подхода Server less. Тоесть цель одна — максимально снизить нагрузку на сервер сняв с него функции формирования динамических элементов HTML,что даёт возможность обслуживать больше клиентов одновременно затрачивая при этом меньше денег на инфраструктуру. Все классические проблемы гетерогенных систем по согласованию данных естественно никуда не деваются. От себя отмечу что недавно поставленная нами система на продакшн успешно выдержала наплыв клиентов в черную пятницу без вмешательств в ее работу. Проблемы не согласованности данных есть, однако по сравнению с проблемами производительности они не столь существенны.

Вот, то о чем я пишу. Чем толще клиент, тем меньше нагрузка на сервер. У толстого клиента есть свое подобие субд и эта субд должна синкаться с сервером, со всеми вытекающими. Особенно это актуально для СПА приложений, где данные тихой сапой подгружаются в фоновом режиме пока ты там чтото проклацываешь или проскроливаешь. Задергивать сервер рефрешами рест апи вызовов, попутно борясь всякими велосипедами с согласованностью данных, ошибочный подход.

Тоесть цель одна — максимально снизить нагрузку на сервер

Так вот оно зачем! А я все мучался мыслью: ну нахера все пихать на клиента?! А оказывается это что бы пользователи новые айфоны быстрее покупали!
Это какой-то позор: с одной стороны построили огромные дата-центры, в облаках миллионы компьют-часов тратят что бы парсить логи (биг-дата — модно) ... а с другой экономят на сервере сформировать HTML страничку!
Ну раз пошла такая мода — то действительно осталось только базу в браузер запихать и будет полноценное десктоп приложение, только в браузере.
А когда-то фантасты думали что персональных компьютеров не будет — все будет на сервере, а клиенту только картинку передавать (прямо на сетчатку глаза проецировать, например).
Вот оно как одно Яблоко повернуло эволюцию вспять! Теперь у каждого юзера по айфону, макбуку, айподу ... скоро еще и по своему яблочному датацентру в чемодане будет:
www.youtube.com/watch?v=0nJh6RH3bzw

Это какой-то позор: с одной стороны построили огромные дата-центры, в облаках миллионы компьют-часов тратят что бы парсить логи (биг-дата — модно) ... а с другой экономят на сервере сформировать HTML страничку!
Ну раз пошла такая мода — то действительно осталось только базу в браузер запихать и будет полноценное десктоп приложение, только в браузере.

Тут я не соглашусь. У тебя в кармане полноценный компьютер с гигабатами оперативы. Зачем дрюкать сервер, если можно задачу разложить на миллионы клиентских мобилок или браузеров.
Причем эта нагрузка самобалансирующаяся. Серверу всеравно, он разложил задачи на 100 мобилок или на 1 миллион или на 1 миллиард. Его роль минимальна. Починить тех кто поламался, проинитить тех кто зашел впервый раз.

Технология работает — доказано пиринговыми сетями типа DC++ и BitTorrent.

Фантасты которые это писали работали в SUN и IBM. Тоесть компаниями которые эти самые мейнфреймы и стойки блейд серверов продавали, вместе с софтом за миллионы баксов. А когда приходит счёт за оплату AWS или ещё хуже нужен бюджет на покупку и обслуживание дата-центра, оказывается что Amazon на твоём интернет магазине зарабатывает больше чем ты сам или бюджет полностью ушел на дата-центр и придется сокращать программистов. Кто выжил — как раз напрягают инженеров менять архитектуру. Толстый клиент и микро-сервисные гетерогенные системы имеют свои преимущества и недостатки аналогично тонким клиентам. Скажем больная боль это мобильные браузеры, устаревшие браузеры вроде IE, не гарантированная производительность на клиенте, задержки в линиях связи и т.д. Это в довесок к перечисленным проблемам с согласованностью данных, сложностью поддержки, необходимости автоматизации процессов, сложности поиска и выявления ошибок и в целом требованиям к квалификации команды создающей и обслуживающей относительно сложную систему.
Пока мы тюнили монолитные системы — все время одно и тоже наблюдал, 80% приложение тратило именно на формирования динамического контента на сервере. В моем случае это в основном JSP были. И в итоге делались дичайшие костыли с кешами и т.п. которые приводили к проблемам как с согласованностью данных так и с горизонтальным масштабированием. Ещё и энтропия кода в придачу вместе с этим. Но даже не это засада, когда чтобы просто перезапустить локально сервер для проверки трех изменений в коде нужно потратить от 20 минут до двух часов — это просто бесит.

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

IndexedDB?

В двух темах по REST я неоднократно высказывал свое мнение, что REST как и любой RPC, не является хорошей зрелой технологией для получения\синхронизации данных

А з чого ви вирішили, що ваша думка є експертною і когось цікавить? У вас немає жодної доповіді, жодної технічної статті на ДОУ, щоб надати вагу вашим словам чи ви самі себе зробили експертом?

А с чего вы взяли, что копипаста с википедии и создание однотипных статей для начинающих про то, что разжовано в миллионе других источниках делает вас экпертом ?
Эксперт, это человек, который видит проблему намного глубже, чем она описана в других источниках. Ввиду огромного узкаспециализированного опыта.
Я пишу о том, о чем вы не прочитаете в других статьях.
Причем я не уменьшаю вашу роль. Индустрии нужен миллион евангелистов и всего один человек бульдозер, который прокопает путь на следующий технологический уровень.

Я не считаю тебя экспертом, ну ты это знаешь, но тут наезд Сергея вообще мимо кассы конечно, учитывая уровень его статей.

Все что рождено на CDC и движках реляционных баз данных уже на взлете мертворожденное.
Корнер кейс тут какой. Что будет если условие в WHERE Name = ’Bob’ поменяется.
Боба удалили и вставили в другое место. А на этого боба ссылалось 50 таблиц. Что в этом случае должно произойти с клиентом ? Какой здесь кафка стрим ? Какие эвенты туда должни прилететь. Идеология с стримом здесь не катит. Стрим != Синхронизация данных

Что будет если условие в WHERE Name = ’Bob’ поменяется.
Боба удалили и вставили в другое место. А на этого боба ссылалось 50 таблиц

Oh my~
Тобто ви не знаєте, що посилаються не на value, а на id (PK)

Срач про синтетичні і природні ключі напевне древніший за більшість інших...

Я вот тоже Брокгауза и Ефрона читал. Два тома прочел. Читаешь, читаешь — слова легкие: РЕСТ, СКЛ и убей бог не помню какой-кто. Книжку закроешь — все вылетело.
Помню только — КАФКА! Какой такой КАФКА? — нет там никакого КАФКА. Там с левой стороны — два ТУФТЕЦКИХ: один — брат ПХП, другой — ЖАВАСКРИПТ, а у меня — КАФКА!".

Что касается эволюции... слепому ясно, что она продолжается. Просто посмотрите на наше (земное) IT с высоты птичьего полета. Глобально посмотрите. Словно если бы вы смотрели видеоролик на учетверенной скорости длиной в 50 лет. И тогда вы увидите то, что будет следующим венцом творения.

Я не ученый. Я настоятель храма технологической сингулярности. Я свидетель бога из машины.

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

2. я бы не пинал REST/RPC или любой другой подход, каждый занял свою нишу и в то же время нет серебрянной пули для решения любых задач.

3. GraphQL хорошая альтернатива для API. много плюсов, я не могу даже назвать существенных недостатков.

4. CQRS + Event Sourcing + микросервисы решаеют проблему описаную в примере

тяжелые запросы по центральной базе данных,

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

PS прошу не судить строго я фронтендер

наверно правильно будет вообще не иметь одной центральной бд, а иметь микросервисную архитектуру с репликациями мастер дб.

Ну о этом и речь. Просто от людей ускользает основная мысль, что на самом деле, между ДОМ обьектом в браузере и моделью данных в самой субд нет принципиальной разницы. На самом деле и то и то субд. И то и то валидирует, хранит, апдейтит, синхронизирует, конвертирует, локализирует, кеширует и тд тп. И такаяже мастер репликация данных должна быть напрямую в браузер.
Отход от этого постулата приводит к тому, что 90% клиентского кода создают чтобы просто наладить комуникационное взаимодействие между браузером и серверной бд, решая попутно самые тривиальные однотипные задачи. Этот код лишний. На первый взгляд это кажется неочевидный и холиварный вывод. Но он неочевидный только на первый взгляд. Просто чтобы это обьяснить придется написать очень длинный пост.

На самом деле и то и то субд. И то и то валидирует, хранит, апдейтит, синхронизирует, конвертирует, локализирует, кеширует и тд тп.

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

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

Отображение, логика поверх данных и сами данные всегда должны быть отделены и там разные подходы для проектирования и масштабирования, это три кита программирования(имхо). Не было и не будет идеальной базы данных.
Исключения составляют узко заточенные кейсы под четкую проблему, но никак не дженерал солюшен.

Просто ты смотришь на апликуху как на кучу данных

Ну я же говорил. Что эта мысль не очевидна. Самое интересное и пародоксальное, что в сложных нагруженных приложениях (типа всяких фейсбукав, линкединах, гитлабах и телеграмах) эта грань между клиентом и субд размывается. Есть понимание что на клиенте сидит ровно такая же база данных, которая умеет синкаться с сервером. И эта база данных занимается и валидацией и секурити и гриды показывает, сортирует и все делает на фронте почти тоже что умеет делать сервер база данных на беке.
В более же простых приложениях, действительно, эта мысль неочевидна. Потому что там вся механика чето быстро по рест дернуть, выплюнуть и забыть. Роль фронт субд там редуцирована до минимума, хотя она на самом деле никуда не исчезает. Трафик тоже не резиновый. И многие задачи по бизнесс логике уже нужно начинать делать на фронте.
До сих пор все развитие субд строения развивалось как четкое разделение на фронт и на бек. Все субд по своим подвидам делились и делятся на те что живут на фронтах и те что живут на серверах. Но на самом деле, опять же, чем сложнее приложение, тем больше оно приходит к тому, что никакого серьезного разделение между хранением и отображением данных — нет. Прото есть разные базы данных которые живут на разных устройствах: в браузере, на мобиле, в вин апликейшин и все они синкаются вместе с мастер базой данных, которая сидит за фасадом.

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

Где там такое есть?

А хз де. Цей перелік взагалі як приклад приводити моветон — їх робота з базою досить примітивна, в багатьох випадках там нафік ACID не потрібен. Може автор не працював з базами в фінансовій сфері/біллінгу?

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

И асид тут непричем. Просто никто не задергивает сервер по мелочам, на малые действия в системе. Например тоже сообщение в ленту пейсбука банально проще вставить в свою локальную базу, а потом уже грузить на сервер. Юзер видит что сообщение добавлено в ленту и рад. Если локальной базы нет, то ты грузишь свою картинку на сервер, а потом ее же читаешь с сервера. Тоже когда ты проклацываешь скрины и табы в апликейшене и они просто грузятся с локальной субд.

Гы. Вот ради интереса, зашел на www.facebook.com, поклацал разные вкладки а потом взял и отрубил интернет на ноутбуке. И что я вижу. Мне внизу показали милый попап что я офлайн и добрая половина приложения в браузере (!) проклацывается как нивчем не бывало. Переключаешся между разными скринами. Конечн,о нужно понимать, что стоило фейсбуку написать такую функциональность и как исголятся чтобы получить ту самую закешированную базу данных на клиенте. Но это единственный верный путь написать сложное отзывчивое приложение и не отправлять на сервера миллиарды лишних запросов.

Мне внизу показали милый попап что я офлайн и добрая половина приложения в браузере (!) проклацывается как нивчем не бывало.

Да ну?! До чего техника дошла :)
Оказывается, на дворе толстые клиенты SPA, приложение в браузере по архитектуре ничем не отличается от своего мобильного или десктопного собрата, а сайты SPA типа ютуба можно вообще установить через браузер и работать оффлайн. Хотя некоторые хотят с бд валидацию прокидывать =\
И да, в браузере тоже есть своя локальная бд, как и всякие там фаербейсы, что умеют работать временно оффлайн с последующей синхронизацией, хотя к делу это не относится.

Я про это изначально говорил. Здесь почему-то думали что такие сайты работают как сайты визитки, ничего не хранят, СУБД на клиенте не нужна. Нужна. И чем серьезнее приложение тем больше нужно поведение СУБД и элементы бизнесс логики именно на фронте.

Хотя некоторые хотят с бд валидацию прокидывать =\

Я так и не понял что в этом плохого если это делается автоматически ? Или дублирование логики это уже Ок ?

что такие сайты работают как сайты визитки

Сейчас даже визитки это SPA.

Я так и не понял что в этом плохого если это делается автоматически

Оно НЕ будет автоматически. Это не зона ответственности БД- ее удел низкоуровневая консистентность данных, выше головы она не прыгнет и не должна.
— на сколь сложную валидацию придется писать хранимые процедуры, одним CHECK SQL там не обойтись, который еще и не везде есть.
— повышение необходимой компетенции бекендера в БД до уровня DBA
— всю валидацию бекенда она в принципе не может обеспечить, в случае чего (а это чего появится с 99% если сервер делает что то еще чем выступает прокси для базы) будем иметь валидацию уже в 3-х местах, и на разных ЯП и подходах.
— ограниченность одной базой — что делать если для хранения частей модели используется несколько бд SQL + NOSQL? Еще одна валидация? А если ее в БД нет?
— что делать если контроллер использует виртуальное поле, которое не отражается в БД, а валидировать надо? Т.е все ровно валидатор ендпоитов нужен, получаем 3 места валидации, а если он есть — нафига нам еще слой на БД? А незачем.
— что делать с OPTIONS запросом, чтобы отобразить документацию по ендпоиту? Где брать данные о параметрах? Дублировать в контроллере? Во внешней схеме? Или как реализовать OpenAPI?
— жесткая привязка всей логики к выбранной БД, заменить на что то другое будет сложно и дорого.
— куча лишних глубоких запросов на запись мимо кеша с клиента
— невозможность сделать preflight запрос на валидацию
— ненужные задержки и низкая отзывчивость UI
— невозможность реализации SPA с таким бэком, про офлайн режим вообще уже молчим

Или дублирование логики это уже Ок ?

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

Зачем такой длинный пост. Давайте покороче. Откройте любой low code, nocode конструктор. Например теже Оракл Формс, Эиртейбл, Баббл. Там просто формы натягиваются на схему базы данных, почти автоматически. Валидацию полей поттягивает от туда же. Вы создали схему ваших данных, натянули формы и вот уже у вас целостностное приложение. Этого достаточно. Там уже все есть. И синхронизация между фронт и бек и валидация и секурити и еще куча всяких плюшек.

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

Зачем все усложнять то ?

3. GraphQL хорошая альтернатива для API. много плюсов, я не могу даже назвать существенных недостатков.
PS прошу не судить строго я фронтендер

совпадение? не думаю

я не могу даже назвать существенных недостатков.

А ты на бекенде это говно использовал?
Вот попробуй написать чтото сложнее круда на говнокьеле, тогда увидишь их, эти недостатки )

Что может быть крепче и надежнее, чем строительные блоки из распределенной крипто информации? Все в крипту (если хотите строить на века)

Итак, какие же проблемы здесь решены. Их всего три:
1. Сервер координально разгружен от выполнения однотипных запросов.

Кто тебе сказал, что это проблема?

Серверы расчитаны на то, чтоб выполнять однотипные запросы. Это то для чего их создают.

И серверы сейчас ничего не стоят, ты за несколько сотен долларов в час можешь в свое распоряжение получить достаточно серверов, чтоб крутить на нем весь stackexchange.

2. Сервер управляет консистентностью данных своих клиентов. На самом деле это неочевидно, но любая распределенная система постоянно борется со своей консистентностью. Распределенные системы должни строиться по принципам восстановления данных, а не копирования чего-то куда-то без анализа с какой версией мы работаем и сколько мы были в офлайне. Как это делает любой RPC колл.

Ты обещал, что будет три проблемы, я не вижу в чем суть второй проблемы. Постарайся описать более понятным языком.

3. Клиент получает данные асинхронно. Это риалтайм обновление данных.

Опять, в чем проблема и как она решается? Реалтайм обновление данных на клиентах уже давно запилили.

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

Что-то подобное было в свое время с knockout.js, офигенно работает как демка и намертво кладет браузер, когда надо хотя бы 100 элементов в таблице отобразить.

И серверы сейчас ничего не стоят, ты за несколько сотен долларов в час можешь в свое распоряжение получить достаточно серверов, чтоб крутить на нем весь stackexchange.

Вот этот аргумент мне больше всего умиляет. Мы будем писать тормознутый код, потому что мощные сервера стоят очень дешево. Сорян, но даже на серверах с терабайтами озу и такими же каналами связи ваш код будет тормозить. Ошибки проектирования прощаются только до определеного уровня.

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

Можно подробнее ? Почему то что делается для того, чтобы все не тормозило, внезапно будет тормозить ? Пример с гитом тут уже приводили раза три. Все создавалось чтобы не тормозило, потом долго это все глючило, но всеже как то отладили и все работает и не тормозит и даже стало стандартом. Зато все, что теперь кроме гита — тормозит.

Видимо потому что:

Серверы расчитаны на то, чтоб выполнять однотипные запросы. Это то для чего их создают.

На счет кнокаута я его код не писал. Ничего сказать не могу.

Что-то подобное было в свое время с knockout.js, офигенно работает как демка и намертво кладет браузер, когда надо хотя бы 100 элементов в таблице отобразить.

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

Мы будем писать тормознутый код, потому что мощные сервера стоят очень дешево. Сорян, но даже на серверах с терабайтами озу и такими же каналами связи ваш код будет тормозить

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

Вот для этого инженеры и нужны, решать конкретную проблему, у тебя же топик про космические корабли и попытки изобрести серебряную пулю.

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

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

Вот для этого инженеры и нужны, решать конкретную проблему, у тебя же топик про космические корабли и попытки изобрести серебряную пулю.

Эти все проблемы одни и теже от проекта к проекту. Велосипеды отличаются, да.

Картинки размер надо уменьшать, это ж для фотографов апка была(там далеко не все фотки жэпэг были), например кто-то залил фотки с фотика которые весят по 10-25 мгб каждая, а тебе надо выводить постранично ленту с фотками, например в его барузере, соотвественно респонсив веб юай, вмещается 10 таких фоток это уже как мин овер 100мгб страниччка, окуеть немножко можно. И тут они и думали — хранить заскейленные/обжатые варианты (разные размеры экранов, вертикальные горизонтальные фотки, различный размер картинок...одного обжатого/скейл варианта не хватит) на харде и дергать те что соотвествую юаю в данный момент или же жать/уменьшать размер фоточек на лету.

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

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

А что самое лучшее могут предложить текущие реалии?

И серверы сейчас ничего не стоят, ты за несколько сотен долларов в час можешь в свое распоряжение получить достаточно серверов, чтоб крутить на нем весь stackexchange.

Я о том, что возможно было так: тебя осенила ослепительная идея.
Ты создал тему. Завтра ты прочитаешь чью-то доку по текущим реалиям и там увидишь описание своей идеи точь в точь.
Для меня все просто: вчера ты заглянул в червоточину. Делориан — она в голове находится. Во всякой тренированной.

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

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

Другими словами, не ломай забор, если ты точно не знаешь зачем его поставили

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

В гугл считали идиотами яху. В майкрософт считали идиотами адептов меинфреймов. Джобс просто считал всех идиотами. В чем вообще проблема ? Это айти детка, здесь 80% идиотов. И даже мой код можно улучшить на 80%, потому что, читай выше.

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

Тебе уже говорили. Что в фаангах сейчас почти ничего не решается. Пишутся стартапы, если они выстреливают, их покупают. Они двигают прогресс. В фаангах месят или существующие технологии или которые уже наперед проданы фаангу за твою скромную зарплату.

В гугл считали идиотами яху. В майкрософт считали идиотами адептов меинфреймов.

Стоит задать вопрос: где сейчас Google/Microsoft и где сейчас Бубен?

Тебе уже говорили. Что в фаангах сейчас почти ничего не решается. Пишутся стартапы, если они выстреливают, их покупают. Они двигают прогресс. В фаангах месят или существующие технологии или которые уже наперед проданы фаангу за твою скромную зарплату.

Опять же, «в фаангах сидят одни идиоты, они только могут покупать чужие идеи, сами ничего не делают». Не видишь повторяющегося шаблона? Ты в скольких фаангах работал, чтоб к такому выводу прийти?

Буду краток. Мне наплевать на твое мнение.
Твоя позиция понятна. Дрюкать сферический литкод, ползти по карьерной лестнице. В любой непонятной ситуации «ставить мощнее сервер» или «в текущих реалиях это был единственно возможный способ решения задачи».
Мне эти шаблоны не интересны, когда можно сделать все по другому.

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

Потому что так больше работы програмистам. Раньше я сайт делал сам. Теперь я делаю бекенд api а три человека фронтенд

Надо еще нанять 2 команды для мобильной разработки: одну под яблоки, одну под андроид!
А ведь когда-то и правда целые ентерпрайз-приложения писали на одном .Net (ну еще SQL) и даже вообще без JavaScript!

Ты же сам видел как ЭТО выглядит, месиво из верстки, дотнета и скл запросов стрингами. Адок похуже того что воротили с рейзором+мвц. Я кстати когда хорошо так поепся с этим месиво таки решил что проще спа и жабоскрипт месить чем снова это. Потом я правда и вовсе отказался от такого фул стэка.
ЗЫ не тут один видал поделки мамонтов.

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

Адок когда там месиво из кода С# + разор + джейсоновские переменные в страничку джейсоном прокидываются а потом жабоскриптом парсят и работают с ним. Вобщем, тебе повезло это не видеть, правда :-)

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

Я хз почему razor хают, довольно годная штука была по сравнению с существующими аналогами.

Можно было ее неправильно готовить (ака засувывать туда SQL запросы и строки подключения, как оратор выше), но то везде случается.

JSF, сцуко, також ще живий, блін. :(

Ничего не понял: начал за REST, а кончил за SQL!
По финалу у меня возникло впечатление что автор заново изобрел репликацию баз данных. Какое отношение это имеет к REST — вопрос не раскрыт.
Судя по названию темы я ожидал увидеть что-то вроде: нахера везде использовать REST (JSON over HTTPS), если бинарная сериализация и TCP каналы намного быстрее?
Читаю про микро-сервисы и меня не покидает чувство дежа-вю: все это уже было с COM и COM+ или JavaBeans + CORBA! Были отдельные компоненты, был сервер, который их хостил и ими управлял, было RPC, которое позволяло вызывать компоненты с другого сервера.
История идет по-спирали. Взлет и падение инженерной мысли. Сначала молодые дураки решили все писать на JavaScript, а только потом начали понимать зачем их папаши придумали ООП языки. И начали лепить в JavaScript ООП, потом строгую типизацию подвезли, а теперь TypeScript уже полностью похож на C#. Вместо 10 лет назад научить браузер понимать C# потребовалось эти 10 лет учить JavaScript быть как C#.
И так со всем: когда-то была мода на XML — везде и всюду. Теперь мода на JSON. Потом внезапно оказывается что бинарные данные компактнее и не надо парсить ... Эврика — пере-открыли gRPC, нашли способ ускорить микро-сервисы!

Приложения, которые чуствуют ускорение от бинарной сериализации это приблизительно 0.001% всех приложений.

Как это может быть? Если вся система на микро-сервисах, то минимум 80% коммуникации между ними «внутренняя». В отличии от 20% «внешней», где данные запрашиваются из браузера (SPA) и нужен HTTPS и JSON.
Более того: во многих случаях целые пачки микро-сервисов крутятся на одной физической машине — при этом общаются по HTTP! Это как «секс по телефону»:
"Ты звонишь Доминиканская республика — они звонят Джава. Джава соседний дом от тебя живет!«© ДМБ
Не представляю как гонять JSON по HTTPS может быть быстрее чем:
— Бинарные данные (без шифрования и парсинга) по сети между соседними серверами в датацентре.
— Бинарные данные через named pipe на том же сервере.
— Memory-Mapped Files — вообще не надо ничего гонять.
И вообще: если у тебя микро-сервисы работают вместе то почему бы им не жить в одном процессе?!
Преимущества микро-сервисов никуда не теряются: их все так же можно отдельно разрабатывать, отдельно деплоить и т.д. Просто меняется «транспорт» по которому между ними передаются данные. По-хорошему микро-сервис должен выставлять интерфейс — а будут его использовать через REST, через gRPC или просто создадут и вызовут — ему должно быть все-равно.

Перепиши все микросервисы на монолит и больше ничего не надо будет гонять по http даже внутри одной машины. Прикинь как это будет быстрее?!!! В 100 раз быстрее чем копеечный сраный выигрыш от бинарной сериализации.

Это еще один холиварный вопрос, который заслуживают свою тему про вопросы к эволюции. Ведь когда мы говорим о микросервисах, что на самом деле мы имеем ввиду ? Что нам продают под видом микросервисов ?

1. Это изоляция кода. Когда каждая комманда может работать над своей маленькой частью системы и быть абсолютно абстрагирована от громадной предметной области, разбираться только в своей песочнице.
2. Это деплой микро сервисов как отдельных компонент, без остановки всей системы
3. Это повышенная отказоустойчивость системы, если какой-то микросервис временно недоступен, вся остальная часть системы продолжает жить.
4. Это горизонтальное масштабирование

А теперь я задам вопрос. Хоть одно из этих свойст, ну может быть кроме 4го но это больше к девопсам, не может быть реализовано в монолите как архитектурный шаблон ? Может. Таже операционная система работает внезапно и как монолит и как микросервисная архитектура одновременно.
Получается то, что микросервис должен быть оформлен обязательно как отдельная юнит единица на отдельном хосте и общатся по рест — не более чем предрассудки от людей, которые не понимают, что на самом деле дают микросервисы архитектуре приложения и какова их суть.

Все правильно.

1. Это изоляция кода.

Чисто организационная проблема! Легко достигается при желании при любой архитектуре и технологиях.

2. Это деплой микро сервисов как отдельных компонент, без остановки всей системы

Если компоненты живут в разных процессах — то это уже позволяет их деплоить отдельно. НО даже если они собраны в один процесс — это не критично! Как происходит деплой или обновление операционки или любой другой процесс в облаках: поднимается новый инстанс процесса, контейнера, виртуальной машины или всего сервера и все новые запросы идут туда. Старые запросы дорабатывают на старой версии, новые идут на новую. Это есть «из коробки» в большинстве систем. Поэтому если даже нужно пере-деплоить 1 микро-сервис из 100, которые живут в одном процессе — то это чисто технический вопрос.

3. Это повышенная отказоустойчивость системы, если какой-то микросервис временно недоступен, вся остальная часть системы продолжает жить.

Вернее сказать если какой-то сервис недоступен то и зависящие от него сервисы «нездоровы». Настоящая отказоустойчивость обеспечивается только дублированием (или «резервированием»). В облаках это обычно есть «из коробки»: одна виртуалка не отвечает — поднимается новая. С базами сложнее — но и там обычно всегда есть standby сервер.
Опять же: как монолит может быть отказо-устойчивым, так и отказ одного микро-сервиса (например, авторизации) — делает «нездоровой» всю систему.

4. Это горизонтальное масштабирование

Вот это действительно большое преимущество микро-сервисов. Особенно в условиях «облаков», где масштабирование может быть динамическим. НО горизонтальное масштабирование это не заслуга именно микро-сервисов. Такое же масштабирование возможно на контейнерах или на виртуальных машинах! Запихни монолит в контейнер — и масштабируй сколько угодно! Если это сложно — то проблема в херовом коде монолита, а не в отсутствии микро-сервисов.
Поэтому я и не понимаю холиваров Монолит VS Микро-севисы. Хороший код, написанный по принципам и лучшим практикам ООП — это уже изолированные, слабо-связанные модули! А дальше хоть вместе их складывай — хоть отдельно раскладывай это уже детали.

Запихни монолит в контейнер — и масштабируй сколько угодно! Если это сложно — то проблема в херовом коде монолита, а не в отсутствии микро-сервисов.

Тут не все так просто, даже если у тебя отличный код в монолите.
Во-первых, монолит скорее всего вряд ли будет stateless — и тут возникают вопросы distributed state, особенно если у тебя autoscaling который ты явно не контролируешь
Во-вторых, это время масштабирования. Простой сервис у тебя будет стартовать единицы-десятки секунд (типа инициализации веб-сервера и пула коннекшнов ), монолит — явно больше, особенно если у него есть какая-то логика кэширования или инициализации

и тут возникают вопросы distributed state, особенно если у тебя autoscaling который ты явно не контролируешь

Это так в стиле микросервисов. Сначала создать проблему, а потом ее героически решать.
Любая инмемори база держит миллионы запросов в секунду. Если ее заскейлить на микросервисы с рест апишечками, хорошо если будет держать сотни запросов. Но зато у нас теперь есть автоскейлинг. Бинго. Теперь мы можем вместо одного монолита который со всем справлялся, держать 1000000 / 100 = 10к инстанцев микросервисов. И конечно один несчастный монолит стартует дольше чем 10к маленьких инстанцев микросервисов. www.meme-arsenal.com/...​eb64d008774955ce165ac.jpg

Угадал все буквы, не смог прочитать слово?

И что по акторам? Кому-то хочется камасутры с оркестраторами?
А ведь трансакцию или RPC между акторами сделать нельзя — вызовы неблокирующие.

А ведь трансакцию или RPC между акторами сделать нельзя

Как нельзя. Для транзакций все что нужно, это механизм отката. Иногда транзакции делают двухфазными в распределенных системах. Некоторые такие транзакции могут медленно выполнятся часами.

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

Распределенные трансакции это или two-phase commit, при котором надо лочить данные на нескольких акторах на время работы логики трансакции (и тут к нам подкрадываются дедлоки и тормоза) — пессимистический подход, или оркестрация/хореография, при которой надо городить дополнительные сущности и продумывать откат изменений (учитывая ливлоки и порчу данных) — оптимистический подход.
Не знаю, кто тут лучше выглядит — оптимисты или пессимисты.
Суть в том, что даже для DECT базы пришлось слепить все существующие акторы в один, чтобы написать логику параллельных звонков. И это — low-end embedded, а не кровавый энтерпрайз.

Не знаю чо там и как и даже не хочу вникать. Суть везде одна, везде функциональный подход. Задача разворачиватся на акторы, также как распеределяется между чистыми функциями в функциональном языке и также сворачивается в результат. С какой стороны не посмотри, этот подход транзакционный не просто как набор костылей, а просто по своей сути. Из-за этого, кстате, гарбадж коллектор в функциональном языке пишется с пол пинка. Он просто там врожденный с мат аппарата. «Транзакция» закончилась, все, давай досвидания, все данные почистили. Таже тема с акторной моделью. Тысяча лиц одного и тогоже.

Ыыы. Это у тебя уже stateless / FaaS.
Чтобы это использовать для реальной бизнес-логики, тебе надо будет гонять между акторами куски базы внутри запроса.
Либо вся логика выборки из базы соберется в первом акторе, и он сам превратится в монолит и сожрет соседей.
Если захочешь лезть в базу из актора — то тебе надо будет запрос от пользователя (а заодно и все данные, которые насобирали предыдущие акторы в цепочке обработки сценария этого запроса) отсылать сообщением в базу, а база тебе это все должна будет потом отослать обратно — ведь ты хочешь актор чистой функцией, не хранящей состояния текущих запросов.

А еще вспомним 1000 и 1 оттенок сценариев с бранчующейся логикой, и как ты это будешь отлаживать без дебаггера (потому что сценарий обработки запроса раскидан по куче асихронных шагов). И об отладке пересекающихся конфликтующих сценариев. И о тестировании асинхронной системы, обрабатывающей ценные данные.

Не совсем понятно. У каждого актора как и у микросервиса есть своя микро база данных. Это микро база данных в 90% случаев хранит его настройки. Про асинхронность тоже не понял. Почему там где строится крассивая фрактальная структура в виде цветка или дерева, должна быть асинхронная лапша с разных сценариев.

Суть везде одна, везде функциональный подход. Задача разворачиватся на акторы, также как распеределяется между чистыми функциями в функциональном языке и также сворачивается в результат.

или же

У каждого актора как и у микросервиса есть своя микро база данных.

выбери, у тебя чистые функции или хранение состояния в акторе?

выбери, у тебя чистые функции или хранение состояния в акторе?

Ну вот представь крону дерева. Каждый листок у него чистая функция ? То что актор имеет свою микробазу еще не означает что будут какието сайд эффекты. Во-первых, в 90% случаев эта микробаза хранит просто настройки этого листка на дереве, этого актора.
Во-вторых, никакой прямой связи одних листьев с одной стороны короны дерева, с другими листьями с другой стороны короны — нет, кроме как через ствол дерева или ветки потолще. Слабосвязанная архитектура однако.

Искореняйте свои процедурные шаблоны. На них ничего кроме лапши не построишь.

Ну давай реальную задачу — на ней покажешь, как растекаться микросервисами по кроне (сценарий отсюда dou.ua/forums/topic/32636).

У нас есть 3 актора: дом, гараж и собачья будка. У каждого из них есть персистентное свойство цвет, и актор может его менять. Это наш data layer.
Также есть бекенд сервисы-акторы: папа и мама. Они обрабатывают хотелки заказчиков.

Сценарий:
* Папе говорят, что надо покрасить дом, гараж и будку в голубой цвет, и убедиться, что цвет одинаковый (транзакция).
* Маме в то же время говорят, что надо покрасить будку и дом в розовый (другая транзакция, возможно — с другим порядком выполнения).
* Кроме того, рядом с папой тусуются гопники и часто подходят чтобы прикурить или одолжить 5 гривен на маршрутку (реал-тайм запросы)
* Пока мама красит будку в розовый, ей еще говорят, что на самом деле надо покрасить будку и гараж в желтый с зеленым горошком. И сжарить яичницу.

Вот у нас конфликтующие распределенные трансакции и параллельные запросы. Распиши, как будут выполняться элементарные действия и где будут храниться состояния запросов (трансакций) в обработке. Если можешь. Если не считаешь возможным реализовать (продумать) такой сценарий — то и распределенные транзакции не поднимешь, и с акторами лучше не связываться.

Да, отказы могут быть на любом этапе: потеря связи между акторами, ребут одного из них, таймауты с последующей досылкой потерянного сообщения. Хорошо эти проблемы описывает Кабанчик в 8 главе.

Ок. Дом гараж и собачья будка имеют один корень. Назовем его коттедж. Сначала папу запускают навести порядок в коттедже и все покрасить. Пока он красит остальные ждут. Рут коттедж заблокирован. Если у папы не получилось покрасить будку, краски не хватило, коттедж возвращается в исходное состояние. Запускают маму.
Да. С виду кажется что система не параллельна. Но она параллельна с точки зрения коттеджного городка, улицы или города. Где одновременно идёт покраска в тысячах коттеджей.

Опа. А акторы ждать или блокироваться не умеют. Это раз.

Дальше, тебе пришлось вводить новую сущность, и завязывать акторов в группу. Для того, чтобы покрасить будку, надо с ней работать через коттедж, а не напрямую. Коттедж будет бутылочным горлышком в системе — все запросы к базе пойдут через один комп. И коттеджи будут завязаны на такое же горлышко — улицу, если вдруг транзакция трогает несколько коттеджей. Или на город — если надо отвезти пиццу из одного дома в другой. То есть, акторы больше не могут работать независимо, и вдобавку получили единую точку отказа.

Три. Пока папа заблокирован, гопники мерзнут. Пока мама ждет папу, дети голодные. И юзеры начнут материться, если у папы пропадет интернет, пока он красит дом, а замерзшие дети и голодные гопники все ждут, пока он разлочится, и не могут обрабатывать новые запросы. У тебя отказ одного компонента повесил всю систему.

Чего то я не понимаю. А ты как хотел ? Чтобы по стене одновременно ерзали валиком папа мама сосед Вася и кум Коля. Так не бывает. Искусство распараллеливания заключается в создании максимально гранулярной единицы. Если бы я хотел распараллелить свой HArray я бы как раз выделил внутри подветки минимального размера и разрешил их обрабатывать одновременно. Поскольку при миллионах ключей там десятки миллионов подветок, тысячи потоков могли бы работать в контейнере паралельно не мешая друг другу забустив скорость работы просто в стратосферу. Но когда в одной ветке ты устраиваешь хаос, эта задача не имеет здравого решения. Это к Мише, у него там чето недетерминированное, я слишком слаб для такого. А ещё мне надо кормить своих детей.

Ну на акторах или микросервисах папа рассылает сообщение «покрасься» на все 3 обьекта; пока они себя красят — раздает сигареты гопникам, а когда получил от всех троих ответ — либо откатывает то, что не покрасилось, и отправляет заказчику ошибку, либо отправляет назад ок, если все покрасились. Это типа оркестрация. И оно бы работало, если бы не мама.

Но согласись, что в любом случае с акторами задача в лоб не решается. А без акторов — решается синхронными вызовами или транзакцией в базу. В этом прикол и суть акторов — как только ты хочешь сделать какой-то действие над несколькими акторами, ты попал. И ты завел специально для этого действия нового актора-гуртовщика. А потом понадобится гуртовщик гуртовщиков. И все может вылиться в распределенный монолит, где бекенд синхронно дергает гуртовщиков через RPC.

Не понял причем здесь мама. Смысл оркестрации что папа запустил маляров на лужайку и стоит возле калитки не пускает маму. Если мама или соседка побежала мимо папы красить будку это не оркестрация, это папа должен вломить пецты кто поламал забор в доме.

А как папа может стоять в калитке, если акторы сами сообщениями обмениваются? Папа тут вообще левый, и забора нет.
А если маму вдруг не пустят, ей чтоб не заблокироваться, надо будет себе положить в очередь запрос на покраску, который сейчас невозможно выполнить. Который в розовый цвет. Чтобы потом им заняться. И начать жарить яичницу. А когда пожарит — выймет из очереди следующий запрос. И это будет — покрасить в горошек. А когда покрасит — выймет следующий, который старый покрасить в розовый, уже протухший. Итого — старый запрос перетер новый. Нарушился порядок событий. Или надо делать акторам интроспекцию очереди сообщений.

snob.ru/...​/87/blog_entry_656944.jpg

Твоя задача как архитектора грамотно бороться с сложностью проекта. Заниматься разделением классификацией и изоляцией. А не строить публичный дом. Иф ю ноу вот ай мин

Ну вот акторы издревле ассоциировались с блекджеком

Даже Мавроди в своем МММ выстроил схему из десятников, сотников и тысячников. Каждый оркестрирует свою группу. Подумай, почему он так сделал, ведь куча десятников хотела управлять счетами не своей тысячи. И ответ — это единственный был шанс упорядочить этих жадных барыг. Акторы вынуждают тебя думать и строить систему так, чтобы ей можно было легко управлять даже если все хотят всем помешать и испортить работу

Вот!
А если эти все асинхронные сообщения заменить синхронными вызовами (или хотя бы большинство), то жить станет проще. И думать не нужно. dou.ua/...​cles/telecom-application

А, еще в тему.
Пока папа красит коттедж, где хранится информация о том, какие объекты он уже покрасил, и какого цвета они были до этого? На случай, если надо будет откатить изменения. У нас же типа «чистые функции» в акторах?

В своем коде я например навешиваю актор патч. Он смотрит что творит его актор хозяин и формирует историю для обратного отката. Все работает буквально в 50 строк кода.

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

Из-за этого, кстате, гарбадж коллектор в функциональном языке пишется с пол пинка. Он просто там врожденный с мат аппарата. «Транзакция» закончилась, все, давай досвидания, все данные почистили.

Вас чекають автори Scala, Haskell, що там ще — допоможіть їм з оптимізацією GC, це ж елементарно. )

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

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

Ну так ты описал идеальную команду из девственных единорогов с фиалками.

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

Это же ***енно, вместо того, чтоб застрять на одном месте, индустрия постоянно куда-то пытается двигаться. Неработающие подходы отваливаются и умирают, работающие продолжают развиваться. Дарвиновская эволюция как она есть.

І навіть пофіг команда, якщо замовник «не адекватний» — а таких більшість, їм класти на puruty, головне "

надо навчера, дешево и качественно

".
Тому все як завжди — вибираються дві опції з трьох :) і до релізу проект перетворюєьться в дещо працююче, але на деякі рішення боляче дивитись.

Та кажуть що в продуктах таке ж — головне фічу в реліз запхать, бо інакше конкурент ринок заграбастить.
Але продукти продовжують жити й розвиватись з отим кодом після релізу))))
І реліз в них не один)))))

Иногда все-таки имеет смысл разбивать на несколько независимых сервисов, если можно так разбить данные на несколько почти отдельных поддоменов и есть четкое понимание какой будет API. Правда такое понимание приходит после написания монолита и некоторых мучений размышлений.
А может быть такой кейс: один сервис хранит пользовательские данные и поэтому деплоится отдельно для каждой страны (данные хранятся в стране по GDPR), в отличие от остальных.
Еще неплохо выделять сервисы непользовательского контента, аналитики, ML etc.

Так и есть! Очень много нагруженных систем написаны как монолиты и работают.
Проблема монолита — она в людях! Код монолита постепенно скатывается в спагетти и потом в навоз. В этом главная причина почему сейчас так популярны микро-севисы — это небольшие куски изолированного кода. Так что даже разработчики, которые не умеют в интерфейсы и инкапсуляцию не могут сделать все публичным и вызывать откуда попало (как в монолите).
Но всю ту же изоляцию можно обеспечить и без физического разделения микро-сервисов! Например на уровне nuget — пакетов. В любом случае чем более универсальное решение — тем больше вариантов его использования. Поэтому микро-сервисы, которые «привязаны» к REST — это не самое гибкое решение, немногим лучше, чем когда все завязано в монолит.

Так потом проблема микросервисов что сервисов тьма просто нахиба они нужны хрен поймешь, продебажить/протестить очень не всегда просто, понять откуда пришел дапрос и понять на каком таком жтапе проявляется этот кейс тот еще гемор, кбернетис, докер и облако(авс или ажур) и прочие перделки тоже надо учить, много команд это всегда кростим комьюникейшен который никто не любит, особенно менджмент, потому что спихивают тухлые таски...
Монолит на микросервисы это шило на мыло в большинстве случаев.

Так потом проблема микросервисов что сервисов тьма просто нахиба они нужны хрен поймешь,

Это часто встречающаяся крайность. Когда микросервисы становятся «наносервисами». Вообще почти всегда процесс выглядит примерно так:
1. Мы прочитали, что микросервисы это круто
2. Больше микросервисов богу микросервисов!
3. ... появлятется 100 сервисов, один на каждый бизнес-энтити ...
4.

хрен поймешь, продебажить/протестить очень не всегда просто, понять откуда пришел дапрос и понять на каком таком жтапе проявляется этот кейс

5. ... большой рефакторинг ...
6. 100 сервисов сводится в 10-20, с примерным соответствием один на бизнес-домен
7. Становится можно жить

Вобщем сколько не пиши, два раза рефачить? :-) Ну так и монолит или SOA с таким подходом легко запилить можно :-)

100 сервисов сводится в 10-20, с примерным соответствием один на бизнес-домен

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

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

Почитай всетаки про акторную модель

Читал еще много лет назад, когда были планы для себе покрутить Erlang (не крутил), несколько лет назад потыкал палочкой в AKKA

Имхо, выглядит интересно как raw data processing и сомнительно для реализации бизнес-логики

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

Менеджить из кода — это как раз единственно правильный способ.

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

Так и есть! Очень много нагруженных систем написаны как монолиты и работают.
Проблема монолита — она в людях!

Проблема в людях — fooool стэках, которые умеют делать всё, и ничего как следует.
Потому что эта блочная квадратно-гнездовая система удобна безграмотному менедженту, тем самым нетехническим продакт-овнерам\пиэмам, которые кэруют-не-вникая.
Берут любого разраба и поручают ему любую задачу, и можно перебросить кого угодно куда угодно.
Удобно: опа-опа, раз-два.

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

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

Не совсем. Синхронизация по сравнению с РЕСТ работает быстрее по следующим причинам:
1. Клиент использует свою закешированную версию базы данных и не задергивает сервер по пустякам
2. Клиент может отправлять и принимать апдейты одним балком (пачкой). А не как набор атомарных колов удаленного хоста как это в РЕСТ.
3. Клиент минует все прослойки вроде маперов, дто и роутинга. Читает и аплоадит свои данные в базу практически напрямую, с минимальным количеством прослоек.
4. Клиент передает бинарные данные, а не текстовые, они более компактные.
5. Клиент может получать свои данные асинхронно. Ему не нужно задергивать сервер постоянно рефрешами.

Открой для себя Event Sourcing — все уже придумали за нас:
www.confluent.io/...​ng-outgrows-the-database

заново изобрел репликацию баз данных

Можно заумное слово репликация заменить словом «копирование».
Тогда можно отсылать любого топик стартера к трудам древних философов, все уже было изобретено до нашей эры.

Читаю про микро-сервисы и меня не покидает чувство дежа-вю: все это уже было с COM и COM+ или JavaBeans + CORBA! Были отдельные компоненты, был сервер, который их хостил и ими управлял, было RPC, которое позволяло вызывать компоненты с другого сервера.

Это все были типичные трехзвенки с RPC. А как я упоминал ранее, по настоящему правильно синхронизироваться (и то с ньюансами) дифами, умеют ресетить и восстанавливать состояние, научил Торвальдс свой гит. Конечно гит это очень узкоспециализированная задача и там нет асинхронных апдейтов, но сами принципы синхронизации они там есть, включая возможность работы в офлайн режиме и пропагейтить свою историю изменений.

Это уже похоже не на СУБД, а на Event Sourcing. Если идея

пропагейтить свою историю изменений.

то и реляционная база не нужна!

Event Sourcing

Это история изменений или транзакционный лог. У него есть свои недостатки, он может быть длинным и избыточным. Поэтому ограничится только им не получится, должен быть микс. База может сделать чесный аналитический SELECT, сделать ресет, а может и досылать тебе историю как Event Sourcing используя свой транзакционный лог.

Замість пари мб коментів — напишіть пруф оф концепт на своєму шарпі чи хоча б на псевдокоді

Це дасть більше користі і розуміння ніж ми вам тут розкажемо, що сама ідея може і виглядає просто, але насправді дико складна
Складна як ЗУБД з розподіленими клієнтами, яким не можна довіряти

Да, код сервера сложен и нетривиален. Но все это делается для того, чтобы сам клиентский код был простым и тривиальным. Написание кода в процессе.

Це ота фігня про гіт для синхронізації коментарів на доу з іншого ракурсу?
facepalm.gif

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

заворачивать телятину в лаваш

А такое в киеве можно купить? Обычно ж вроде куру строгают в лаваш.

ЧСВ у трейні щось зовсім з катушок злетіло

ЧСВ

Мне не жалко, могу подиграть =)


Гения сразу видно хотя бы потому, что в борьбе против него объединяются все тупицы и бездари.

© Джонатан Свифт

ты там попей микстурок, а то окажешься в одной камере с наполеоном

Вынужден огорчить. Гениальность это проблема. Связана с нарушением синхронизации между обычным индивидуумом и тем, кто нечаянно раскрутил свой мозг, скажем на 15% больше. Возбуждение нейронов. В этом состоянии нейроны лепят в код гения вообще все, что им приснится. Разобрать этот код стоит больших усилий даже ему самому. На следующий день.
Не допускайте перехода ваших мозгов в стадию даже граничающую с подобными уровнями работы. У вас просто где-то там в голове выгорят все вкусняшки, со временем.
Горение такого рода должно быть приглушенным.
TDD очень помогает взять собственную гениальность в самые жесткие рамки.

Причем сервер не выполняет (!) запрос заново, он идет по более короткому пути,

Вам будет нужно каждое событие на сервере фильтровать через все подписки с «where». Т.е. ваш «короткий путь» может оказаться не совсем коротким.

Он не короткий если у нас одновременно висит миллион активных клиентов.
Но все же он намного короче если каждый из миллиона клиентов захочет сделать Select.
Это первое. Второе, индексы никто не отменял. Если миллион подписок, их можно сгруппировать и уникально проиндексировать в своей микротаблице. И вот уже не нужно бежать по миллиону подписок фулсканом.

Вообщем ребята, я Вам врал. Я прилетел с 2050 года, чтобы начать Эпоху возрождения в IT.
В этом каменном 2021 году Вас обманывают.
Вас обманывают с базами данных (должни быть не рав базы а доменные, ленивые кожанные девелоперы, напишите нормальные субд),
Вас обманывают с парадигмой ООП (АОП намного эффективней, но о этом как нибудь в другой раз)
Вас обманывают с RPC\REST (должна быть человеческая синхронизация\восстановление данных)
И вас обманули даже с поисковыми алгоритмами (но это другая история, тема кому надо тот найдет, причем вместе с бенчмарками).
К сожалению никаких других рецептов, кроме как проехаться бульдозером по трущобам которые наворотили сотни тысяч айти евангелистов — нет.
"О очевидных вещах люди думают реже всего"© Макс Вебер
Придется делать роллбек развития с откатом эдак лет на 40 назад и возвращаться на правильные рельсы развития. (К сожалению долететь в 1970й год к братишке Алану и пустить правильных ход истории, не могу, мощности гравицапы не хватило, делориан не вывозит)
Всем добра.
Sarcasm off

І як там в 2050 поживає «СУБД Днiпро»? )))

Ну как бы да, так можно делать, это уже описанный паттерн, типа CQRS, когда мы подписываемся на события и строим read model под нужды конкретного сервиса. Но почему ты противопоставляешь его RPC ? Сходить получить данные через сетевой запрос по трудозатратности реализации значительно проще чем хранить свою локальную версию этих данных и реализовать подписку на все возможные ивенты чтобы ее поддерживать up to date. Поэтому да, люди выбирают рест, потому что его сделать проще и быстрее, и только когда реально упираются в ограничения такого подхода — инвестируют ресурсы в то что ты описал. Там кстати проблем тоже немало с консистентностью, гарантией доставки, распределенными транзакциями и прочее.

типа CQRS, когда мы подписываемся на события

Вот тут есть принципиальная разница. Мы подписываемся не на события как таковые. А на получение всех данных которые удовлетворяют нашему запросу. Это меняет ход дела. Поскольку в данном случае нам не нужно продумывать топики, эвенты, их гдето хранить и както передавать, обрабатывать потерю эвентов. Нам нужен просто запрос и на основе него будет «материалайзед вью», только на клиенте.

Сходить получить данные через сетевой запрос по трудозатратности реализации значительно проще чем хранить свою локальную версию этих данных и реализовать подписку на все возможные ивенты чтобы ее поддерживать up to date.

Проще только потому, что современные базы данных так не умеют. Они перекладывают эту ф-сть на плечи разработчиков. Вот вам raw данные, сами заботитесь о копировании этих данных, передаче по сети, контрактах, дифах, эндпоинтах и тд.

И тут мы подходим к ключевому вопросу. Какова минимальная единица сервиса, в которой оправдан РЕСТ. На мой взгляд, таких серисов почти нет. Разве что сервисы которые требуют прямой экшин, типа отправь имейл или смс. Во всех остальных случаях, даже если мы возьмем просто страницу с комментариями такую как эту, уже полезны не обновление страницы раз за разом, а асинхронное обновление локальной копии.

Поскольку в данном случае нам не нужно продумывать топики, эвенты, их гдето хранить и както передавать, обрабатывать потерю эвентов. Нам нужен просто запрос и на основе него будет «материалайзед вью», только на клиенте.

Реальность шлет тебе привет.
Твои события, отосланные на клиента, могут теряться. Они могут приходить дважды, если потеряется ответ от клиента. Клиент может подписаться дважды, если потеряется твой ответ ему. Либо тебе надо держать открытыми по TCP соединению на клиента, и это тоже толком ничего не гарантирует. В результате — твой сервер сам должен будет под каждого клиента держать у себя очередь событий, которые этот клиент еще не получил. Те же 100 000 очередей, только теперь — внутри движка твоей базы. А база еще может скрешиться или бутнуться — и тогда 100 000 клиентов ее положат одновременным запросом «а где мои данные?»

Твои события, отосланные на клиента, могут теряться. Они могут приходить дважды, если потеряется ответ от клиента. Клиент может подписаться дважды, если потеряется твой ответ ему.

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

В результате — твой сервер сам должен будет под каждого клиента держать у себя очередь событий

Сервер не держит очередей. Сервер знает о подписке. Подписка может содержать какойто condition что этому клиенту нужны все данные по какому условию WHERE Name = ’Bob’.
И если ктото будет делать INSERT(Name) VALUES(’Bob’) то этот инсерт автоматически улетит клиенту. А если не улетит, сервер прибьет подписку. В следующий раз клиент обратится, окей, я был Ок на состояние час назад, есть что новое для меня по этому условию ?

Да, сами принципы синхронизации, они не простые. Но они — все находятся под капотом. Все это делается для того, чтобы координально уменьшить трафик и нагрузку на сервер.

Все что нужно клиенту, это хранить версию своих данных и оповещать сервер, какая версия у него текущая и какая версия актуальная.

То есть, ты хочешь хранить снепшоты? Рбычно в базах снепшоты хранятся только до тех пор, пока есть хоть одна трансакция (включая репликацию), которая сидит на этом снепшоте. А тебе надо хранить вообще все, потому что вот завтра вылезет клиент, который месяц назад закрыл лептоп и уехал в отпуск, а завтра он вернется, откроет, и клиент полезет в базу выгребать дифф за последний месяц.

И если ктото будет делать INSERT(Name) VALUES(’Bob’) то этот инсерт автоматически улетит клиенту.

А откуда ты знаешь, что он клиенту прилетел? Из версии снепшота, которую клиент когда-то потом пришлет? Отсылать будешь по UDP или по TCP? Если по TCP, то сокет все время открыт, или переоткрывается на каждое сообщение?

То есть, ты хочешь хранить снепшоты? Рбычно в базах снепшоты хранятся только до тех пор, пока есть хоть одна трансакция (включая репликацию), которая сидит на этом снепшоте. А тебе надо хранить вообще все, потому что вот завтра вылезет клиент, который месяц назад закрыл лептоп и уехал в отпуск, а завтра он вернется, откроет, и клиент полезет в базу выгребать дифф за последний месяц.

Нет, сервер хранит историю изменений. Эта история изменений набор эвентов, каждый из которых атомарная операция над базой данных. (в простонароде транзакционный лог) Если нам пришел неизвестный клиент в лохмотьях, с битой базой данных, все что нам нужно, узнать его версию базы. Допустим это версия на 20501128 ... ой простите ... 20211128. Сервер берет цепочку эвентов и прогоняет через conditions подписки клиента. Допустим из этих 1000 эвентов в тразакционном логе только 100 относится к клиенту. Он их досылает как диф. Клиент накатывает этот диф. Админы, девопсы и девелоперы тоже накатывают по рюмочке. И даже сервера, на которых куллеры можно теперь активно не крутить.

То есть, снепшоты не хранятся, и каждый клиент чтобы проинициализировать свою базу должен прогнать все изменения на сервере с самого рождения этого сервера? Или сервер снепшотит базу, и имплементит и селект, и подписку?

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

Алгоритмы конечно здесь не тривиальны. Точней здесь еще терпимо, а вот там где начинается офлайн клиент и вещи типа резолв конфликтов и кейсы, а что если подписка на которой основывался клиент WHERE Name = ’Bob’ внезапно изменилась. Например запись Bob удалили, а на нее ссылалось еще 100500 записей. Получается клиенту нужно прислать какойто балковый диф, который удалит все записи.
Там уже сложнее.

Но нужно понимать для чего нужно городить такую космическую станцию. Все это делается для того, чтобы невероятно упростить код самого клиента. Клиент теперь, это просто код который работает со своей локальной базой и знает что она всегда в актуальном состоянии. И даже если ты написал в своем приложении всего 100 строк кода, ты получил очень живучую модель распределенных данных, которая умеет восстанавливать свое актуальное состояние и которая может держать огромные нагрузки или даже автономно жить какое то время в офлайне.

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

Ну а запись в базу? Ты же упомянул конфликты — вот клиент запишет себе в базу, а на сервере примерно в тот же момент кто-то другой пушнул изменение в той же записи. И че будет? А у клиента уже окошко закрылось — он же успешно записал в локальную базу.

Ну а запись в базу? Ты же упомянул конфликты — вот клиент запишет себе в базу, а на сервере примерно в тот же момент кто-то другой пушнул изменение в той же записи. И че будет? А у клиента уже окошко закрылось — он же успешно записал в локальную базу.

Тут есть два режима работы.
1. Если клиент работает в офлайне, он строит свою локальную версию, свой бранч. При выходе в онлайн, он пытается синхронизировать свой хвост истории с сервером. Если конфликтов нет, он синхронизировался. Если есть, резолвит конфликты.

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

Ага, то есть, код для сохранения данных у клиента проще не стал. Даже наоборот — появляются два варианта сценария вместо одного сейчас.

код для сохранения данных у клиента проще не стал.

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

Но твое приложение заблокировано на вызове в базу пока она не синкнется с сервером?
То есть, код приложения должен синхронно записать в базу?

Если это онлайн режим то да. Тоесть если бы доу страница комментариев была бы построена по такой схеме, то клиентский джаваскрипт просто добавлял один элемент в дом дерево у себя локально. Он бы был 1-2х строчным. Без всяких рест, сабмитов и прочей чепухи. А внутри это тригерило уже синк с центральной базой данных.

Так вот же вопрос что будет, если у себя он добавил, а на сервер не смог залить. Как пользователь это увидит? У него локально его коммент есть, а на сервере и у других юзеров этого коммента нету?

Ну вот клиентский код, ступид, работает со своим локальным дом. Сложность в одну строку.

dom.insert(comment);

и под капотом у самой субд

void insert(comment)
{
    if(insertToServer(comment))
    {
            var patch = getLastPatchFromServer();
            dom.applyPatches(patch);
     }
}

Вопрос, на сколько времени эта функция заблокируется при обрыве связи, DNS проблемах и подобном. И будет ли при этом скроллиться страница, и будут ли доступны другие виджеты.
Если что, я в вебе не разбираюсь.

я в вебе не разбираюсь

Частина тих хто розказує, що вони розбираються не знають що таке днс
sad_kek.webp

Вопрос, на сколько времени эта функция заблокируется при обрыве связи, DNS проблемах и подобном. И будет ли при этом скроллиться страница, и будут ли доступны другие виджеты.
Если что, я в вебе не разбираюсь.

Ровно также как сейчас работает доу сайт. Вставка на сервер и для рест и для кода выше будет условно одинаковой (хотя в моем случае чуть быстрее за счет уменьшения количества абстракций, возможности балковых апдейтов но не суть).
Вставка в локальный дом можно принебречь, поскольку это маленькая локальная бд с одним юзером, на ней все операции мгновенны.

Ну я же не знаю, как сейчас оно устроено. Вроде, не блокируется. Но бывают более сложные сайты. Тот же Линкедин.

Если не блокируется то это уже офлайн режим, со всеми вытекающими. В таком режиме ты вообще можешь не ждать ответ от сервера и колбасить свою локальную историю в надежде что все засинкается как надо без конфликтов.

Да, и что будет, Если юзер пока первый комент шлется на сервер напишет второй комент и отредактирует первый? Как при этом сработает

dom.applyPatches(patch);

и какие изменения юзера оно потрет?

Да, и что будет, Если юзер пока первый комент шлется на сервер напишет второй комент и отредактирует первый? Как при этом сработает

Так у юзера однопоточный режим. У юзера же нет как у кришны 10 рук, он набирает один коммент, клацает добавить и на время добавления блокируется вся его локальная субд, пока она не засинкается с сервером.

и на время добавления блокируется вся его локальная субд, пока она не засинкается с сервером.

О, вот об этом я и спрашиваю. То есть, при плохой связи сайт на минуту повиснет. Совсем повиснет. Намертво.

О, вот об этом я и спрашиваю. То есть, при плохой связи сайт на минуту повиснет. Совсем повиснет. Намертво.

В онлайн режиме да. Ровно также как сейчас если случайно пропадет связь с интернет.

Да нет, сейчас пока написанный коммент висит и ждет DNS, можно спокойно себе крутить другие ветки, лайкать даже кажется что-то.

А ще дані у клієнта ті, які він захотів і не валідовані на сервері

Мммм
Яка крута система

Вообще в нормальных системах всегда двухуровневая валидация. Первая — на клиенте. Чтобы не дергать сервер по пустякам. Вторая — на самом сервере, подтвердить что клиент прислал валидные данные и не жульничал.

Чтобы не дергать сервер по пустякам

Це зроблено для поліпшення UX і на великих формах часто робиться часткова валідація для подальшого введення даних на клієнті

І коли кліент мухлює, то вам не треба кодити rollback на клієнті

Це зроблено для поліпшення UX і на великих формах часто робиться часткова валідація для подальшого введення даних на клієнті

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

На клієнт відправляються словники/довідники

Форма відправляє не значення, а ід ентіті
Дозвіл на вибір тієї чи іншої ентіті може керуватись логікою на фронті

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

а в привычной имплементации их тягают с сервера постоянно

developer.mozilla.org/...​TTP/Headers/Cache-Control
Ні, не тягаються
Ніякої магії. Все давно працює

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

KISS

картинках

якщо це дрібниця, то що тоді «не дрібниця»?

Открой тему нищая Европа. Там одних комментариев на 10 мегабайт. И внезапно, кешем браузера такое закешировать нельзя. Но хотелось бы.

Що більше при передачі по хттп?
100mb images VS 100mb html

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

Це ж не філософське питання
Що в сучасному вебі більше важить при переачі по мережі

Зображення/медіа чи текст?

Говорят что в современном интернете под 80% трафика это ХХХ контент. Что, с такой логикой, теперь кешировать только ХХХ, во всех остальных местах кеш уже не нужен ?

Тут нужно понимать. Что с точки зрения клиентского кода, кеширование вообще ничего не стоит. Твоему коду до лампочки. кешируется там что-то или нет. Главное чтобы была последняя актуальная версия. Получается весь разговор сейчас, что сложно заимплементить субд часть. Ну да, сложно. Но это смарт кеширование нужно заимплементить всего один раз и оно распространится на все приложение. Голова перестанет болеть, что куда отправлять, откуда брать, как фиксить корпшенные данные, как читать и тд. Вся эта магия будет за кадром.

Відповіді на моє просте питання я так і не побачив

Якщо ви зможете реалізувати отк ваше магічне смарт кешування, то вам подякують багато компаній з fortune500

Ага, так мы тут обсуждаем не реальное состояние дел а некую мифическую еще не изобретенную технологию? Ну тогда да, наше воображение может нарисовать мир гораздо идеальнее чем на самом деле )

Если серъезно, то

Мы подписываемся не на события как таковые. А на получение всех данных которые удовлетворяют нашему запросу. Это меняет ход дела. Поскольку в данном случае нам не нужно продумывать топики, эвенты, их гдето хранить и както передавать, обрабатывать потерю эвентов. Нам нужен просто запрос и на основе него будет «материалайзед вью», только на клиенте.

Можешь диаграмку нарисовать как ты это видишь? Как и когда сервер оповещает о подписке, что сервер будет делать если клиент не ответил, как клиенту понять что его версия аутдейтед и запросить фулл рефреш и прочие каверзные вопросики.
Допустим даже мы смогли разрешить проблемы синхронизации со стороны сервера и клиента и пускай сервер дает эту функциональность out of the box, ты уверен что прям каждый клиент будет счастлив строить свое вью, поддерживать его, бэкапить и прочее вместо простого получения данных от сервера тогда когда это нужно и в том формате в котором ему это нужно.

Есть еще один интересный момент. Одна из фишек реста — мы скрываем за интерфейсом внутрянку и можем менять ее как нам нравится пока контракт остается неизменным. Даже если контакт меняется — его сравнительно просто поддержать, так как клиент каждый раз получает свежую версию данных.
В твоем случае мы завязаны под текущую схему и вот просто так решить что «мы будем хранить данные подругому» уже нельзя, потому что всем клиентам придется перестраивать свои вьюхи.

Допустим даже мы смогли разрешить проблемы синхронизации со стороны сервера и клиента и пускай сервер дает эту функциональность out of the box, ты уверен что прям каждый клиент будет счастлив строить свое вью, поддерживать его, бэкапить и прочее вместо простого получения данных от сервера тогда когда это нужно и в том формате в котором ему это нужно.

Клиент и сейчас строит этот вью. Прямо этот пост находится в ДОМ модели браузера.
Здесь ничего не меняется, кроме того, что теперь этот ДОМ могут патчить дифами без перегрузки страницы.

Есть еще один интересный момент. Одна из фишек реста — мы скрываем за интерфейсом внутрянку и можем менять ее как нам нравится пока контракт остается неизменным. Даже если контакт меняется — его сравнительно просто поддержать, так как клиент каждый раз получает свежую версию данных.
В твоем случае мы завязаны под текущую схему и вот просто так решить что «мы будем хранить данные подругому» уже нельзя, потому что всем клиентам придется перестраивать свои вьюхи.

На клиенте есть своя локальная подножная база, а над ней вьюхи, любых зоопарков. Так работают большинство серьезных приложений (с офлайновой базой данных), от мессенджеров до социальных сетей и даже игровых автоматов казино на 10000 игроков одновременно, цель которых не просто задергивать сервер своими рефрешами.

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

Так работают большинство серьезных приложений (с офлайновой базой данных), от мессенджеров до социальных сетей и даже игровых автоматов казино на 10000 игроков одновременно, цель которых не просто задергивать сервер своими рефрешами.

Так работают некоторые типы приложения для которых этот тип архитектуры более подходит под юзкейс.

Вообще меня доу начал разочаровывать. Вместо чтобы вести серьезный разговор, обсуждать серьезные архитектурные вещи я теперь захожу в свою тему и вижу вверху экрана огромный банер с вайти вайти футбольным тренером в трениках. Причем не заметить его невозможно. Физиономия любителя кожаных мячей продублирована дважды.
Ну нахрен.

Просто ты расстроен, что твои посты не лайкают (какая неожиданность!), а посты твоих оппонентов в дискуссии залайкивают (вот пидарасы, нихя не понимают в айти, один ты только знаешь).

Может, пора задуматься и надрачивать на графкл молча? )

Ну вот я предложил серьезно обсудить диаграммы последовательностей для модели с пятью акторами

Можно ли центральную базу данных написать так, чтобы клиенты вместо того, чтобы каждый раз дергать SELECT ... FROM ... WHERE на базе, просто подписывались (subscription) на изменения данных и сервер просто досылал новые данные которые подпадают под запрос клиента.

О, Бубен вдруг узнал про существование микросервисов external-content.duckduckgo.com/...​illy-Wonka.png&f=1&nofb=1

Микросервисы работают немного не так.

Во-первых, если это сервис бас (без сервис бас там все еще намного хуже), там есть топики и есть месседжи которые прилетают в эти топики. Количество топиков ограничено, не может быть 100 тыс топиков, у клиентов нет личного топика.

Во-вторых, Порядок прилета сообщений не детерменирован. Соответственно ты сам должен хендлить как-то порядок обработки сообщений. Часто это важно.

В-третьих, Ну и самая большая проблема, сервер не заботится о твоей консистентности. Если ты ушел в офлайн, а потом «проснулся» то нет встроенного механизма реабилитации твоей консистентности. Нет той меджик кнопки, что хоп и ты теперь уже весь такой консистентый, даже если часть сообщений гдето протухло в дедлеттер очередях.

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

Ну паб/саб можно редактировать. Снепшот вынуть из базы последний, а сверху накатывать очередь сообщений. Как делают для поддержки реалтайм OLAP копий из OLTP оригинала.
А создать топик на клиента никто не мешает. Или можно в один топик насадить много клиентов, если у них запросы одинаковые.
А вот как ты со своей моделью «база внутри клиента» будешь обрабатывать ребуты 100 000 клиентов, после которых каждый клиент будет делать полный SELECT чтобы подтянуть себе зеркало базы, которая небось в оперативе лежала — это уже интересный нюанс.

Ну паб/саб можно редактировать. Снепшот вынуть из базы последний, а сверху накатывать очередь сообщений. Как делают для поддержки реалтайм OLAP копий из OLTP оригинала.

В современных реалиях это называется Event Sourcing. И проблема опять же, что его нужно реализовывать вручную. И очередь этих самых сообщений будет для каждого клиента своя. И избыточность этой очереди присудствует, поскольку какие-то записи могли удалятся\добавлятся по несколько раз.

А вот как ты со своей моделью «база внутри клиента» будешь обрабатывать ребуты 100 000 клиентов, после которых каждый клиент будет делать полный SELECT чтобы подтянуть себе зеркало базы, которая небось в оперативе лежала — это уже интересный нюанс.

Как раз эта проблема существует если не применять тот подход о котором я говорю. Если твои клиенты постоянно делают SELECTы, то при ребуте они вполне могут захотеть все вместе зарефрешится. Если их базы данных пускай даже в оперативке, они всеголишь попросят дослать дифф чтобы догнать версию их данных до последней актуальной версии. А дифф этот понятное дело значительно меньше чем полный снапшот данных. И получить этот дифф намного проще чем сделать полный селект. Возможно даже не понадобятся индексы по базе, но это не точно.

Я говорю о ребуте клиента.
Вот есть браузер, и он смотрит Линкедин.
Клиент в браузере делает тебе селект, чтобы создать у себя копию базы контактов и сообщений, и обновлять ее в реалтайме событиями от тебя.
Закрыли браузер — копия базы потерялась.
Какая нагрузка селектами будет на сервер?

Я говорю о ребуте клиента.
Вот есть браузер, и он смотрит Линкедин.
Клиент в браузере делает тебе селект, чтобы создать у себя копию базы контактов и сообщений, и обновлять ее в реалтайме событиями от тебя.
Закрыли браузер — копия базы потерялась.
Какая нагрузка селектами будет на сервер?

Ок. Какая альтернатива ?

1. То как работает ейчас
Ребут. Селект, Еще селект, Еще селект. Еще селект, селект селект селект .......

2. То как должно работать.
Ребут. Селект. Диф диф диф диф (досылается асинхронно по мере изменения данных на сервере) ......

Кажись оно и сейчас диффами работает. Причем распределенными — судя по тому, что можно написать сообщение в теме, и еще пол-часа его там не видеть.

Это вообще единственная верная модель построения приложений с множеством клиентов. Для меня загадка, почему RPC\REST еще на коне. Это худшее что могли придумать для синхронизации данных. И то что он пишется проще, это слабый аргумент. Да, он пишется проще, только потому что кто-то поленился в движок субд внести нормалные механизмы синхронизации данных. Если бы внес, то свой линкедин ты бы написал еще даже быстрее чем набросал REST эндпоинтов. Эндпоинты просто не нужны если у тебя твоя личная база данных.

В плані синхронізації даних нічого кращого ніж РСУБД напевно немає, бо там все іде через лог транзакцій. Ти завжди можеш привести репліку до стану основної бази. Синхронізувати клієнт із даними в базі це окрема задача, зовсім інша.

Это если тебе нужно синхронизироваться 1 в 1. Если нужно синхронизироваться не 1 в 1, (а иерархиями) то внезапно оказывается что ничего хуже РСУБД не придумано.

та много воркараундов придумали. Например в кафке есть компактед топик — топик с ключом, где меседжы не удаляються, а с одинаковым ключом перезаписываються (сохраняя последовательность). Таким образом, если клиент потерялся, он просто перечитывает топик с начала и до конца полностю воссоздав картину, или что у него там.

Сам как считаешь ? Ровное решение ?

Ну мы эт юзаем. Оно проблему более мение консистентного лога решает. Лог только должен быть с полными данными по ключу, а не с инкрементальными апдейтами.
Но эт бекенд, где клиентов не так много, они жирные + в случае ролбека подождать пару часов на перекеширование не проблема. Как это с фронт клиентами может работать — хз.

С какого перепугу вдруг

GraphQL

более зрелая технология? Глючное, тормозное г-но, которое хипстеры суют везде куда не нужно.

Мы тут говорим про концепции, а не про конкретные реализации и уж тем более хипстеров.
Сама концепция что ты задаешь шаблон (запрос) того что тебе нужно и сервер тебе возвращает именно это, не присылая ничего лишнего, она правильная. И тормознутой и глючнутой быть не может по определению.

Сама концепция

концепция у graphql — RPC

Да, это RPC. Но в отличии от REST, где задача напедалить как можно больше прмитивных эндпоинтов, под ними напедалить еще столько же дтошек, потом под ними еще столько же мапперов и всяких роутеров, GraphQL не занимается этими игрищами, а ходит на сервер буквально через один эндпоинт. И при этом покрывает уже на взлете кучу контрактов и уменьшает трафик обмена информацией.

При этом я не считаю GraphQL каким-то совершеноством, но то что он на голову выше REST, это очевидно.

Появляются проблемы производительности так как модель графкл!=модель в БД

Мне вот интересно, почему так стараются разьединить модель в БД с Юаем. В некоторых случаях оно может и полезно, но на практике. Например если взять этот сайт есть всего два домена. Это юзеры и темы. И если мы запихнем например все коменты в одну реляционную большую таблицу, то каждый раз, когда юзер делает рефреш страницы, эти данные нужно клеить все вместе. Причем клеить их в таблице, где эти комментарии лежат не рядом на диске, а в разнобой. Получается в 90% случаев данные должни лежать так, как они отображаются на юай. И по большому счету пофиг на аналитические запросы. которые удобней запускать по одной большой таблице. Потому что аналитических запросов мало и могут подождать админы, а отображение страницы оно вот, по сто штук в секунду.

А бек-енд уже не в моде? Кеширование, сохраненные процедуры, индексирование?

Бекенд уже не в моде. Точнее он сильно похудел. Поскольку единое приличное место для валидации, кеширования, секурити, синхронизации, транзакционности и др. фишек бекенда — это слой который ближе всего к данным. Тоесть субд.

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

Рукалицо.
0. Масштабируемость
1. Стоимость

0. Масштабируемость
1. Стоимость

Приличные субд, которые славятся своими способностями к горизонатльному (читай дешевому) масштабированию, сами балансируют нагрузку, включают и выключают шарды, создают и поддерживают свои реплики, голосуют за мастер и другие фишки. Все реализовано в тойже Монге и настраивается девопсами.

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

Приличные субд, которые славятся своими способностями к горизонатльному (читай дешевому) масштабированию, сами балансируют нагрузку, включают и выключают шарды, создают и поддерживают свои реплики, голосуют за мастер и другие фишки. Все реализовано в тойже Монге и настраивается девопсами.

Ты что-то слышал о CAP теореме?

Ты что-то слышал о CAP теореме?

Не совсем понятно на что ты намекаешь. Типа ограничения CAP теоремы накладываются на подкапотное пространство тойже Монги, но не накладываются на твои бекенд фавелы, которые ты собрался писать ?

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

Теперь я понял откуда берутся *фуллстек* девелоперы — это фронт-ендер который любит мешать коней и людей...
Я конечно *мимо крокодил* но, по моему котлеты разные, отдельно — фронт-енд отдельно.
Если все мешать, то закончится тем, что: для получения масштабирования а*2 придётся выделять ресурсы r*r. Разделение, (приблизительно) дает r*r/n (где n, количество обособленных доменов).
Если я ничего не перепутал, триста лет не занимался архитектурой.

Ничего не понял. Давай на пальцах. Самый простой пример.
Предположим есть в субд поле NAME на нем висит логика валидации. Не пустое. Не более 64 символов. Назови мне хоть одну причину, почему эта логика валидации вместе с настройками должна быть продублирована = отдельно на фронте и отдельно на бекенде. Почему не в одном месте ?

То есть на каждый чих делать запрос на реверс прокси, который постучится на сервис, а сервис к бд, чтобы сказать юзеру, что введенное имя не прокатит, после того как наконец вбил капчу с 3й попытки на форме в 10 полей? Спасибо, но такие интернеты 2000-х пусть остаются только в воспоминаниях.

С тем что ты какой-то странный чесс слово, скуя ты смешиваешь даже не бизнес логику, а фронт валидаторы и базу? Схера база должна там чет валидировать юзеру, если достаточно отвалидировать на фронте и не пихать в базу всякую дичь? Ты представляешь какое говно будет код чтобы волочить ошибки из базы на апишку, а потом на веб морду юзеру!?
Трай кэтчи по всем уровням приложения еще и с постоянныой проверкой сообщений захардкоженых чтобы перевести язык ошибок базы на человеческий! Ну а главное, каждый раз блть гонять форму и перегружать страницу!!! Рак формы блть!

если достаточно отвалидировать на фронте и не пихать в базу всякую дичь?

Я тебя поздравляю. Завтра я по вкладке F12 в браузере в два клика отключу твой жаба скрипт валидатор и вуаля. В твою базу теперь можно вставлять все что угодно.

Вот для этого это и делается. Чтобы если контракт поменялся в СУБД, он моментально был применен сразу в двух местах, на фронте и на самой субд. А не всяким криворуким джунам давать валидировать все на фронте, забыв про бек. Куа конечно такое пропустит, а вот кому надо, дыру с размерами в глобус, конечно не пропустит.

После Ф12 у тебя нисхера не заработает на фронте, даже формочка не улетит на сервер в большинстве случаев, но для шибко умных ставят валидатор на самом топ левеле апишки в котроллере и там оно в пару строк в экшене валидирует и выплевывает ошибку юзеру. Никакой бизнес логики и тем более базы.
Фронт может проверять на регулярку поле, валидаторы могут взаимосвязанные, динамические формы, связанняе списки по типа выбери страну а потом область а потом город, ты это все хочешь в базу засунуть!?!?!...Такое впечатление что я с джуном или наркоманом общаюсь, ей богу.

Эх, ностальгия. Я так в свою бытность ломал чаты. Все потом удивлялись, почему у меня не такие как у всех цвета и другие эксклюзивные фишечки с аккаунтом. Просто отключил их джаваскрипт валидаторы и запихнул туда что хотел. Эх, времена же были.

связанняе списки по типа выбери страну а потом область а потом город, ты это все хочешь в базу засунуть!?!?!

А сейчас оно где хранится ? Материализируется откуда ?

Разделять отображение, логику и данные даже джуны умеют, худо бедно но умеют, тебе же этого так и не научили. Пиши что хочешь.

Это разделение есть, оно просто более продвинутое. Когда у тебя две СУБД одна на фронте вторая на беке, это разделение сводится к трансформации данных при репликации с Бека на фронт и обратно. Причем оказывается эта трансформация работает значительно проще и правильней, чем три слоя приложения которые черезмерно распухают и размазывают логику.

Мне вот интересно, почему так стараются разьединить модель в БД с Юаем.

Потому что вся совокупность хранимых данных !!!= тому что хочет/должен/может видеть конкретный юзер в конкретном юзкейсе на конкретном фрагменте отображаемого юая.

Я тебе уже раньше говорил, что ты нихя не понимаешь в данных и CQRS, вот ты сам это только что своими словами подтвердил.

Потому что вся совокупность хранимых данных !!!= тому что хочет/должен/может видеть конкретный юзер в конкретном юзкейсе на конкретном фрагменте отображаемого юая.

Так я о чем говорю ? В идеале на фронте должен быть свой индивидуальный срез базы данных. И в описании темы есть запрос который делает этот срез на клиент.

на фронте должен быть свой индивидуальный срез базы данных.

Бред.

Я рад что ты оценил. Выгодно отличается от твоих постов где много текста, но мало смысла :-З учись забесплатно

Давай я уточню, ты предлагаешь мне хранить данные не по их внутренней структуре, а так, как будет удобнее юаю их забирать, верно? То есть, очень грубо говоря, сделать модель зависимой от представления, да?

Давай я уточню, ты предлагаешь мне хранить данные не по их внутренней структуре, а так, как будет удобнее юаю их забирать, верно? То есть, очень грубо говоря, сделать модель зависимой от представления, да?

Скажи чем MVC отличается от MVVM.
Чем трехзхвенка отличается от микросервисов. Ты уже проспал этот момент. Уже больше нет никаких сакральных мега конверторов из базы в вью. В микросервисах страница по сути поделена на виджеты, виджет тянет свои данные с микросервиса у которого бизнесс логики очень мало на то и микро. MVVM говорит что больше нет говнокода с мегаконвертором а есть трансформация одной модели в другую и натягивание сверху дизайн шаблона. Поэтому бобер выдыхай. Эта революция уже произошла.

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

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

В книжке Ричардсона по микросервисам они определены как кусок кода, который может поддерживаться командой, накормляемой одной-двумя пиццами. То есть — тима 5 чел. И такая тима может напилить дофига кода. А микро они по сравнению с монолитом. То, что пишется на коленке в количестве 100 штук — это наносервисы, и они не взлетели (и АККА тоже не стала стандартом разработки).

Если руководствоваться твоим правилом с пицами, получается любая команда до 5 человек должна проектировать и всегда собирать монолит. Это странный критерий. Основной смысл микросервисов в микродеплоях, фолт толерантности и изоляции комманд между собой.

Да, если есть одна команда, то нет смысла ее саму от себя изолировать. И нет смысла огребать девопс проблемы и асинхронщину, пытаясь играть в микросервисы.

И Ричардсон, и Фаулер рекомендуют начинать с монолита, а когда монолит разросся до неподдерживаемости (monolith hell) — тогда начинать от него отделять сервисы, постепенно, от кусков, которые более-менее сбоку и новых модулей, до середки. И до середки даже не дойдет чаще всего на практике.

Есть картинки с трудозатратами на микросервисы и монолит
martinfowler.com/...​-verdict/productivity.png
Вот нет смысла делать сложно, пока можешь сделать просто

So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.
martinfowler.com/...​/MicroservicePremium.html

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

Чем проект на 100 тысяч строк и 100 таблиц которые наколбасили 5 человек за год, отличается от проекта на 5 таблиц и 10 тысяч строк которые наколбасили 10 пицеедов за тотже год ?

Как вообще должни выглядеть эти архитектурные митинги ? Шат ап нас все ещё меньше 5 человек !

Как вообще должни выглядеть эти архитектурные митинги ?

Какие митинги? Их не было упомянуто.

Чем проект на 100 тысяч строк и 100 таблиц которые наколбасили 5 человек за год, отличается от проекта на 5 таблиц и 10 тысяч строк которые наколбасили 10 пицеедов за тотже год ?

Очевидно же: тем, насколько фигово новичку в этом коде разобраться))) Увеличение количества сильносвязанного кода в 10 раз замедлит разработку. Когда разработка станет невыносимой — пора делить кодовую базу.

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

Ну очевидно же — потому, что если начнешь сразу подкладывать соломки в каждую лужу в окрестностях — то никогда не дойдешь до работы. Сначала надо сделать дело как попроще, и тогда увидишь, в какую лужу сядешь. KISS.

KISS

Ну я этот принцип понимаю так, что если сомневаешься делать проще или сложнее, делай проще. А не делай проще там где точно знаешь что это проще не выстрелит. В некоторых проектах какие сервисы должни быть выделены в самом начале, понятно уже через пять минут изучения ТЗ.

Оно в теории круто звучит. На практике:
-напедалить одну модель (с графом всех зависимостей) мож быть не тривеально, особенно если база данных уже дана.
-прально кверить этот граф это тож не очевидная задача.
В резульате нород забивает, и просто фигачит отдельные квери с отдельными схемами, с отдельными дтошками итд итп.

Оно в теории круто звучит. На практике:
-напедалить одну модель (с графом всех зависимостей) мож быть не тривеально, особенно если база данных уже дана.
-прально кверить этот граф это тож не очевидная задача.
В резульате нород забивает, и просто фигачит отдельные квери с отдельными схемами, с отдельными дтошками итд итп.

Конечно это нетривиальная задача. Поэтому вся эта логика должна уйти под капот базы данных и база данных сама должна этим всем заниматься. Освободив клиентский код от головняка. Современные же субд берут свою родословную от файловых систем и примерно там же и остались. Тоесть они тебе дают хранить рав данные и дальше сам прыгай как хочешь с зависимостями, орм, синхронизацией и тд. Спасибо что хоть в некоторых констреинты да транзакции добавили. И на том спасибо.
Субд должна хранить домены. А домен, это агрегат рут + немножко бизнесс логики. И тогда клиентский код, абстрагировавшись, просто работает с доменом. Ему всеравно какие там где зависимости, как и куда они будут синхронизироваться. Потому что его единица взаимодействия с субд — домен.

Это все уровень «космические корабли бороздят просторы голлактики». Следующий запуск (китайского) человека на луну запланирован на 2036 год. Нам надо шото попроще, вжух вжух и в прадакшен в условиях когда хакахчег понятие не имеет чего хочеть.. Рпц с субд в этом плане отлично работают

запланирован на 2036 год.

До 2049 года должни успеть. В 2050 там уже все хорошо.

В 2050 там уже все хорошо.

Мне тут из 2050 сообщили что твоя бд не взлетела, и боевые корабли на подступах к Ориону координируются друг с другом на джаве 1894 версии на спринге, хибернейте хттп версии 5.1.

Папа Бенедикт 18й объявил графкл богомерзкой ересью еще в 2039, а в библию записали что Иисус творил чудеса выполняя запрос

POST world/v2/miracles/resurrections
authorization: Bearer Jesus
{
   "person": "Lazarus"
}

200 OK

Підписатись на коментарі