Проектирую архитектуру чата
HTML-код
- Опубликовано: 12 сен 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
Как же я соскучился по таким видео от Соера! Спасибо, было очень полезно и интересно!
Переосмыслил свой текущий домен. Было полезно, спасибо.
Просто великолепное разъяснение, огромное спасибо, будет очень полезно и на прохождении интервью, и на работе.
Не особо понятен смысл видео, автор упустил ответ на вопрос и при этом начал описывать MVC паттерны и прочее не имеющее отношение к вопросу, которое имхо можно было бы пропустить. Тут важны были детали именно реализации отношений
Спасибо за твой комментарий, я думал, схожу с ума. Кругом хвалебные комментарии под пустым по содержанию видео.
Соэр, давно смотрю твой канал. Благодаря твоим видео понял что такое архитектура и как правильно ее воспринимать. Негативные комментарии идут от малого числа дураков, которые никогда не поймут что ты говоришь. Смотри на лайки, много людей очень ценит твой контент, не обращай внимания на дураков и не переставай вести канал.
К сожалению, хороших курсов по архитектуре нет, люди не понимают базовых вещей, но хотят чтобы за 15 минут им открыли "истину", которая сделает из них архитекторов, но чудес не бывает. Так что я понимаю, что проще обвинить меня в некомпетентности, чем работать над собой.
Вот обожаю логику "если негатив - значит завистник или дурак". Откуда такое ограниченное мышление? Почему ты отвергаешь версии о том, что человек может быть не согласен с мнением автора? Или автор - это истина в последней инстанции и всегда, без каких либо исключений, прав?
@You Tube неуверенность делает тебя смешным. Ты ставишь вопросы после каждого утверждения, скрываешь имя... Не тебе давать оценку Соэру, он в миллион раз умнее тебя и компетентнее. Сначала сделай хоть что-то, чтобы тебя не за бота можно было считать, потом пиши свой бред.
@@S0ERDEVS Привет, а скажи пожалуйста, куда надо подписаться - на патреон или ютуб чтобы начать изучать архитектуру?
@@РоманВойтукты школу закончил?
Я извиняюсь конечно, но сейчас в доброй половине приложений есть:
1) клиент-серверная архитектура
2) Контроллер
3) Сервис
4) Сущность "юзер".
И еще базу данных можно нарисовать. Всё это примерно так и связано. Но это слишком общая архитектура получается. Важны всё таки детали
как то скомкано, вроде почти 17 минут, но какими-то боольшими мазками. реально автру интересно стал понятен ответ на его вопрос или нет?
Автор видео старался, но в видео есть много точек роста. Как такого самого проектирования тут показано критически мало.
Чем больше проект, тем мощнее себя раскрывает архитектура
Приятно тебя послушать, спасибо!
Отличный канал. Спасибо автору
1:35 спалили палитру кистей Криты) От меня как от художника мое вам уважение!
Вот здесь получается все продумывается заранее. Хотел уточнить а возможно ли применять итеративный подход. Например по пользовательским историям. Как в таком случае вообще применять проектирование, или это является альтернативой и в итоге все изменения мы имплементируем сразу в код?
Я кодить то толком не умею, а тут чёт капец интересно
Соер, здравствуйте! Наверняка вам этот вопрос уже неоднократно задавали, но я ответа не видел. Расскажите, с помощью чего вы рисуете на экране?
графический планшет это называется
у него шаринган
@@user-ew6vd4ud3z что такое шаринган?
@@igor8219 одно из Сандай Додзюцу
Спасибо за видео 👍
Спасибо !
Хотелось бы еще что-бы ты разъяснил про то, как правильно выстраивать модели и архитектуру для реализации подписок на пользователей. Как в инстаграм, к примеру.
Подписка - это сервис, который знает как получить информацию о пользователе, знает как сохранить информацию о том на кого подписан пользователь.
Долгосрочное хранение - функция сервера, сервис обращается к серверу чтобы обеспечить долгосрочное хранение данных.
А клиент отвечает за отображение и получение данных о подписках, для этого он использует сервис.
Сама структура подписок, пользователей и т.д. - это модели.
@@S0ERDEVS Спасибо за ответ!
Вот как раз таки со структурой моделей не совсем понятно, как лучше все выстроить, что бы это было удобно все использовать. Был бы рад получить информацию от Вас!
По-моему автор вопроса под формулировкой "архитектура приложения" имел в виду банальное "какие таблички мне создать в бд, какими ключами их между собой сцепить и какие должны быть запросы выборки в конкретных случаях". Не буду спорить с автором канала на тему первостепенности выбора шагов при решении подобной задачи, однако предполагаю, что части негативных комментариев можно было бы избежать, приложив к видео простенькую схемку архитектуры бд + несколько живых sql-запросов по предложенным бизнес-кейсам.
не то, за что зацепился и начал объяснять автор канала (конкретный шаблон реализации клиент-серверной архитектуры)
Подскажите, можно ли интегрировать модуль в монолитную архитектуру? Или лучше микросервис разработать для монолита?
Поправьте меня, но ведь клиент (пользователь) должен получать только те сообщения, которые ему предназначены?
То есть бОльшая часть логики реализуется на сервере?, данные хранятся в базах (например в реляционной с использованием many-to-many связи через промежуточную таблицу), пользователь забирает с сервера/подписывается на - свои сообщения, которые уже на клиенте распределяются по комнатам, доступным пользователю.
Было бы здорово увидеть продолжение этого видео, с разбором серверной архитектуры и реализацией fullstack MVP на основе этих набросков. Понятно, что требований может не хватать, но польза обучающего видео в практике, которую можно подглядеть и начать думать ближе к мышлению автора
Спасибо
Комната и пользователь могут быть связаны не напрямую, а опосредованно через третью сущность под названием подписка. А подписка будет ссылаться на пользователя и на комнату.
Пользователь подписывается именно на комнаты, а не на сообщения. Делать many-to-many между пользователями и сообщениями это абсурд
Охренеть 🤯 наконец-то начинаю понимать, как подходить к архитектуре и как её дальше отображать на фреймворк. Лет 5 назад промаялся полгода с руби он рейлз, и забросил. А надо было вот с этих схемок начинать!
Блин ну рельса довольно проста в изучении
Уважаемый Соер)
Твой контент уникальный среди десятков каналов и групп, на которые я подписан.
Надеюсь подписчики не повлияют на него, требованиями типо: "Почему не рассказал что такое контроллер? Я просто в деревне, здесь интернета нет."
Таких видео, с рассуждениями, очень не хватает.
Обычно включая видео, начинает болеть голова в ожидании зачитывания документаций.
А за эти 16 минут, с уровнем понимания архитектуры как у подписчика, который задал вопрос, я получил удовольствие, стало понятно куда копать, как мыслить и что ожидает, если решиться сделать такую задачу грамотно, а не костылями.
Каеф, лайк.
Мне кажется, автор вопроса (как и большинство тех, кто негативно высказался о видео) путают архитектуру и проектирование отдельных классов(или таблиц в БД). Спросил про архитектуру и тут же скачок на более низкий уровень абстракции - как сделать композицию в классе и нужно ли это делать. Вопрос был про архитектуру и Соер по минимальным данным на него ответил. Архитектура же про слои и их изолированность, про группы классов, про обмен данными между ними. IMHO, конечно)
В общем телегу описали...
А мне почему-то больше интересует, как спящий телефон мгновенно просыпается при входящих сообщениях?
Телефон не щадя батарею постоянно поддерживает соединение? Есть подозрение, что тут не всё так просто...
Хороший формат, спасибо
Спасибо, очень полезное видео!
Побольше бы таких видео о проектировании архитектуры
Спасибо за ролик, но есть вопрос.
На 4:55 была высказана мысль о практически полном отсутствии требований в формулировке вопроса. И утверждение, что именно требования должны определить всю архитектуру, вплоть до того, монолит это будет или микросервисы.
Но... после этих слов внезапно было начато проектирование и в результате создан то ли первый вариант, то ли ядро архитектуры. Это - нормально?
Может, так оно на практике и работает - заказчик высказал какую-то хрень, думать некогда, разговаривать с ним тоже, херакс-херакс в продакшен, а там посмотрим?
S0er, возможно ты перед проектированием предположил недостающие требования (из своего опыта, есс-но), и уже на основании своих гипотез начал прорабатывать архитектуру? Тогда хотелось бы понимать, из чего ты исходил, что сподвигло к созданию именно такого количества слоёв и объектов.
Ведь далеко, далеко не всегда это всё нужно.... Не мог бы ты озвучить, хотя бы примерно, каких целей достигает озвученный подход?
Архитектора прикольная. Хотелось бы ещё услышать как сохранить согласованность данных и определить причинно-следственные связи. Получится ли так, что пользователь отправит сообщение, это сообщение увидит другой пользователь, а в базу в итоге не запишется. Это уже конечно зависит от конкретной реализации, но было бы прикольно посмотреть на эти примеры
Кайф! Как же ты ахеренно раскладываешь!
Спасибо тебе, соскучились
Поделитесь плз о каком видео идет речь - про архитектурные стримы на 0:46. Всё смотреть нет времени, но какой-то конретный - посмотрю с радостью.
Спасибо
Привет. Что для начинания нужно читать из книг по архитектуре?
Класс!
Здравствуйте! А какую ЭВМ вы используете в повседневной работе?
Многоуважаемый S0ER, хотел бы попросить Вас, объяснить, что такое контроллер, по всем остальным частям понятно, а вот слово контроллер не укладывается в голове, что же оно такое и с чем его едят. Понятно что термин контроллер - значит контроль или управление. В конечном исполнении сервис - служба к примеру, а что контроллер непонятно(, ясно, что служба ждет чего-то, а как проходит жизненный цикл контроллера - не пойму, но интуитивно предполагаю, что он реагирует на входные данные. Был бы благодарен Вам за разъяснения.
в этом и фишка Соера. Он часто не рассказывает то, что гуглится по первому запросу.
Контроллер обрабатывает входные данные в адекватный вид для сервиса и возвращает данные в необходимом виде клиенту
@@sergeyharchenko5116 это не фишка, а не умение преподнести инфу систематизированно
Что если пользователь не отправил ни одного сообщения в комнату, но находится там в качестве слушателя, получается комната должна знать о пользователе?
Действительно, удивительная ситуация! Человек бесплатно выкладывает ТОП контент. Он на лету генерит решения, которые расширяемые и рабочие, их можно править и дополнять, но они уже рабочие. Если говорить совсем коротко, у всей молодой поросли, которые ассоциируют себя с IT отсутствует культура создания ПО (о культуре общения и вообще жизни в социуме, говорить просто не приходится). То что автор говорит об этапах создания ПО, они даже не воспринимают и обычно называют это водой! "Ты мол нам про код говори, че ты лечишь??" это позиция кодера, цена ему 60тр в тучные годы и то переплата. Еще много написал бы, но времени нет. Автору большое списибо, виден опыт и глубокие знания по разным аспектам создания ПО. Успехов!
да, контент просто ТОП, чтобы хейтить такие материалы, надо быть немного одноклеточной амебой.
По вашему всегда надо только хвалить?
Вот ради интереса вы на патреоне поддерживаете соера или только словесно?
@@doc-jp2bf не знаю, а ты как думаешь?
@You Tube ваша адекватность под вопросом, отойдите от клавиатуры дальше, от капающей слюны может случиться короткое замыкание. Напоминаю о прописанных вам лечащим врачом препаратах, необходимо срочно их принять. Берегите себя!
обожаю твой канал!
Я хоть и для ПЛК софт разрабатываю, но слушать все равно интересно. Не все понятно, но жутко интересно!
Извиняюсь спросить, что такое ПЛК?
@@merxan2417 Программируемый Логический Контроллер, или PLC по буржуйскому. Железки, которые промышленным оборудованием управляют.
а потом лид приносит правки от заказчика и все идет к чертовой матери...
Здравствуйте, есть такой вопрос, во время учёбы в ВУЗе или в школе вы участвовали в олимпиадах по спортивному программированию?
О, скоро как раз чат делать, возьму за основу)
Привет, большое спасибо за контент, хочу задать вопрос или попросить освятить такую тему, как SaaS, а именно организация архитектуры сервиса (b2b), который поставляется сразу нескольким организациям-кастомерам, наибольший интерес тут именно к тому как хранить данные каждого кастомера (организации) и не пересечь их друг с другом? Ведь в одной базе хранить конечно можно, но тупо страшно. Независимые виртуалки под каждого? Может выйти дорого по железу и как-то сложно. Есть ведь еще такой термин как multitenancy, но у него несколько интерпретаций. Очень хочется узнать где истина, потому что сейчас занимаюсь именно таким проектом
Сколько ни гуглил никак не могу найти материал о том как грамотно строить SaaS
на самом деле возможны разные решения в зависимости от конкретных требований. я не Соер, но у меня в небольшой практике были и по одной базе на клиента и когда несколько клиентов в одной базе живут. при этом отдельные базы - это не обязательно отдельные виртуалки, вполне можно на одном сервере несколько клиентов (в любом случае нужна автоматизация разворачивания). В общем это такая штука что тут и знания девопса нужны технические и по разработке и глобальное понимание какие сервисы и т.п. чтобы выбрать баланс плюсов-минусов того или иного решения в конкретном случае.
Зависит от количества организаций и как часто они будут добавляться
много проще начинать с конца, а это tdd. а что если не писать тесты. Вопрос! не является ли эта схема апогеем разработки
Нихрена не понял, но начал понимать, что нужно начать понимать.
Бляяя.. примерно такаяже мутатень у метя происходила первые два года в ит, печалька
Я освоил декомпозцию после того как разобрался в Django с его MVC.
Дак я не понял. Если в комнате не будет храниться список пользователей, то как пришедшее в эту комнату сообщение найдет всех своих адресатов?
Наберет на мобилу
На бэкенде в базе будет храниться конечно. А на фронтенде это и не нужно, там получатель только один.
Почему так мало кто говорит о сокетах, webrtc, oauth2?
Если комнате user не нужен, то ч зачем она нужна??? (
Архитектура не терпит скомканности! (с)
Подскажите пожалуйста, если я оплачиваю на патреоне подписку уровня Workshop Donate я получаю доступ к архитектурным стримам И к воркшопам? Или только к воркшопам?
И к стримам, и к воршопам.
Нужна таблица юзеров, сообщений, самих чатов. В остальном дело логики.
А где и что почитать по архитектуре? Есть курс какой-то или книги?
Есть видео на канале, называется "5 книг по архитектуре ПО, которые стоит прочитать в 2021". Там 5 книг + ссылка на патреон, где есть расширенный список.
I'm from Senior Software Vlogger
Небольшое пожелание по качеству видео. На заблюренный экран неприятно смотреть, глаза с ума сходят. Черный кусок экрана (как раньше) для схем был бы лучше.
За архитектуру несомненно респект, всегда интересно посмотреть.
наоборот, норм.
Соблюден нынче модный и привычный формат говорящей головы - и визуализация информации на фоне её. Лучше, чем квадратик, который торчит в каком-либо из углов экрана, занимая место, а то и загораживая контент!
опять дед бухтит
Безусловно, любую задачу можно разбить и подогнать под ту или иную архитектурную модель. Однако, мне кажется, вопрос был не только об архитектурной основе чата, но и максимально эффективной связке комната-юзер. При абстрактно верном ответе, все же остается нерешенным вопрос, как лучше сделать эту привязку. Насколько мне ясно из видео, сообщение хранит все данные, но ведь эти данные - следствие, а не причина.
Связка хранится вне комнаты и юзера, их связывает сервис, который может делать это любым способом, обычно хранение реализуется где-то в БД на сервере в виде пар внешних ключей.
@@S0ERDEVS В таком случае, почему сообщение вообще имеет отдельную ценность? Возможно, более верным решением будет DTO типа "event" которая хранит данные о любой активности и сообщениях в том числе? В таком случае, можно будет составить полную картину в любой момент, без лишних итераций поиска и сопоставлений...
@@md5login не понял вопроса, сообщение - это обобщение над возможными типами передаваемых данных "event", "command", "text".
@@S0ERDEVS Это именно то, что я имел в виду. Вопрос снят, спасибо.
@@S0ERDEVS Разве в терминах DDD - комната не является агрегатом для пользователей и сообщений? Если так, то получается что комната будет хранить и то и то.
Последние 2 минуты это краткий гайд как пройти собес на разраба)))
Ух как сложно, сложно вычленить какую нибудь теорию
Сделайте пожалуйста видео по фреймворку radare2
Давненько не было слышно тебя
Правильно ли что сервисами здесь называется класс который имеет поведение но не имеет состояния - то бишь симплДоменМодел ?
Где то в мире техо плачет один кактус
То есть модели анемичные будут.
да.
В коментах есть джу....?)) Вам дали главное архитектурное решение для чата - месседж это серебренная пуля и даже некий god object все остолное вокруг него - реализуйте как хотите. Работаю в конторке где один из продуктов мессенджер. Вся архетектура как описанно в видео - а парни кто делал под него архитиктуру почти год ресерчили телегу инсту твитер слак вк вичат лайн и т.д. и как оказалось - везде так. Тока не нада что все слизали друг у друга... сделай подругому, а когда упрешся в проблемы маштабируемости, ботов, шаблонов, бесед, групп и ой там б много еще чего тогда и ответишь.. И понятно что автор вам тут мессенджер не напишет, так как это один из самых сложных продуктов (ну для тех кто незнал).
Одни из самых сложных продуктов это банковские сервисы, биржи, логистика. Это на много порядков сложнее мессенджера
А где же СОЛИД и +100500 паттернов ?
В идеальном мире собеседований)
Меня запутало. Если чуть конкретнее, то 2 вещи которые я вынес из видео, которые меня сильно смущают.
1) Комната это модель данных
2) Посередине между всеми сущностями есть сервис
1. Окей комната это модель данных, но разве других моделей нет? Сообщение и юзер это тоже модели данных
2. Скалывается такое ощущение из видео, что модели ничего друг о друге не знают, и все это обмазано сервисами, которые знают все обо всем. Тогда возникает вопрос а как же сервисы хранят информацию о этих связях?
На мой взгляд комната и юзер действительно не связаны на прямую, те не зацеплены. По тому как комната связана с сообщением, и юзер связан сообщением. Но вот сообщение должно, обязано хранить ссылку и на комнату и на юзера. На этом этапе мы еще ничего не должны знать ни о каких сервисах, иначе все становиться запутано.
1) Комната модель, в том смысле что она имеет атрибуты:
- id
- описание
- имя
т.е. модель несет описание комнаты
2) Сервис - это логика, сервисов много и они решают задачи:
- получить список комнат
- получить список пользователей
- сопоставить пользователей с комнатой
а сообщение - это объект передачи данных, он таскает в себе информацию, которую используют сервисы, чтобы изменить свое состояние.
@@S0ERDEVS Хорошо, сообщение изменяет состояние комнаты.
- Как получить список своих сообщений без привязки к комнате? Нужно просканировать все комнаты, выцепить там только свои сообщения? Немного это не правильно.
Еще раз сообщение изменило состояние комнаты. Это означает что нет реляции между пользователем и сообщением. Сообщение это не вода, которую выгрузил из одной емкости и загрузил в другую.
@@S0ERDEVS " которую используют сервисы, чтобы изменить свое состояние" - мы предпологаем что сервисы хранят состояния?
@@doc-jp2bf
1) Я сразу обозначил, что все пляшет от сообщения и его структуры, в структуре сообщения предусмотрено как "Room", так и "User", чтобы получить все сообщения User-а, нужно фильтровать по User-у, чтобы получить все сообщения по комнате, нужно фильтровать по комнате.
2) Клиент серверная архитектура предполагает хранение стейта на сервере, а на клиенте только "отображение" этого стейта, соответственно, если вы хотите что-то фильтровать на клиенте, то это идет в разрез с выбранным стилем архитектуры
3) У каждой сущности есть состояние, у сервисов, у контроллеров, у роутера. Сущность без состояния - это null (хотя отсутствие состояние, тоже можно рассматривать как состояние)
Но в любом случае мы не знаем какие у нас задачи (об этом сказано в видео) и какие ограничения. Видео описан общий принцип построения архитектуры клиент-серверного приложения с разделением ответственности, конечную архитектуру надо строить с уточнением требований.
@@S0ERDEVS "чтобы получить все сообщения User-а, нужно фильтровать по User-у" Фильтровать по юзеру что? Состояние комнаты (комнат)? (Еще раз зафиксирую мысль, сообщение меняет состояние комнат, но само при этом не является сущностью)
Нагородил сто пятьдесят тысяч абстракций и сделал приложение, которе не запустится ни у одного клиента
Отличный контент, удивляет, что многие пишут не совсем объективные комментарии (негатив), скорее всего сказывается недостаток опыта, у таких комментаторов.
Рекомендую книгу: system design interview An Insiders's...
Там есть глава: design a chat system
Видео объективно ни о чём. Всё что ты описал и так понятно, обычный mvc. Лучше бы ты рассказал какие именно технологии ты бы использовал на каком этапе, чтобы обеспечить максимальную скорость и оптимизацию при работе с большим колличеством подключений. Если мессенджер был бы десктопным, то что есть комната? Нужен ли ей свой Server socket или использовать один на весь мессенджер? Не понятно.
Вода же. Просто по верхам водички полили и пошли дальше.
Напиши конкретнее чего не понял, постараюсь уточнить в следующих видео.
@@S0ERDEVS не обращай внимание, очередной вкатывальщик в айти зашел не на тот канал. Я очень рад что ты выпустил ролик! Очень полезно.
@@S0ERDEVS имхо, слишком мало внимания уделено взаимодействию бизнес-сущностей друг с другом и обоснованию того, почему бизнес-сущности должны быть выстроены именно так. В видео речь идет больше о программных сущностях - архитектурных компонентах.
Но отмечу и довольно полезную мысль из видео - про необходимость избавления от привычки сразу пытаться уместить бизнес-требования в парадигму конкретного языка/фреймворка.
@@ilyazyabirov4884 я готов обсуждать любые предметные мысли и критику, но я не могу помочь человеку что-то понять, если он не написал ничего предметно. По сути воду в видео только пара человек увидели, остальные смогли довольно интересные мысли написать.
Бис
Божественный ответ с полезностью ~ 0. Дрочка абстракций вместо конкретной помощи по конкретному вопросу. Полезность на уровне рассказа о принципе работы двигателя внутреннего сгорания в ответ на вопрос "как завести машину".
Гегель переворачивается в гробу
Дружище, я бы рад помочь тебе разобраться, но ты напиши что ты хочешь понять. Конкретно на поставленный вопрос я ответил почти сразу - объединение в композицию комнаты и пользователя недопустимо, почему тоже объяснил в видео.
Более правильная декомпозиция тоже есть в видео. Чего не так-то?
@@supervichka7764 ааа, вот это ты жжешь))
Действительно, божественный ответ с полезностью . Если вы не поняли его, то пересмотрите еще раз, и подумайте. На мой взгляд это весьма полезная информация, о которой не только лишь все думают. Соер подробно рассказал, почему автор вопроса столкнулся с проблемой, и показал вариант решения ее проблемы. И да, чтобы завести машину нужно знать хотя бы отдаленно принцип работы ДВС. Вдруг, у вас там бензин закончился, или мотор вообще стуканул?)
MVC/MVP/MVVM - худшее, что могли придумать в программировании
А можно немного конкретнее?