Transcription
[музыка]
Уважаемые слушатели, всем добрый вечер. Мы готовы начинать наш вебинар на тему "От идеи до MVP: Как создаётся архитектура IT решения шаг за шагом". Сегодняшний вебинар проведёт Мира Карлаш. Мира является экспертом в нашей школе Systems Education, также инженером по требованиям, экспертом в области применения Data Science в медицине с фокусом на диагностику и анализ данных для сложных заболеваний. Сам доклад Миры.
Основная часть нашего вебинара продлится примерно 25-30 минут. Далее последует блок вопросов. Тож Мира, я передаю тебе слово.
Да, спасибо большое. А всем привет. Соответственно, сегодня проведём вебинар. План у нас такой: мы посмотрим от постановки задачи и требований. Далее смоделируем данные, после чего проговорим про сценарии взаимодействия интернет-технологии и форматы передачи, проговорим прост, асинхронное взаимодействие, современные подходы к интеграции и далее финальный обзор архитектуры проекта.
У нас с вами будет обучающийся пример, точнее пример для обучения. Это платформа для онлайн оббучения, на которой преподаватели могут создавать курс. Потом модерация курса происходит перед публикацией. Далее регистрируются студенты, проходят курсы эти, сдают, а, тесты, получают сертификаты, получают уведомления о дедлайнах и новых материалах, а также результатах. И непосредственно, а потом мы проанализируем прогресс студента.
Соответственно, всё это строится на нашем курсе по а архитектуре MVP, который будет состоять из следующих ступенек. Первое - это проектирование архитектуры, наша первая ступенька. Далее реализация базы данных. Потом внутрисистемная интеграция, связываем фронт с БЕКОм, потом внешняя интеграция, связываемся. Я расскажу про технологический стек поподробней с Telegramботом и непосредственно почтовым уведомлением сервисом. И так далее. Идёт у нас потоковая инонтеграция и визуализация данных.
Соответственно, основной функционал - это создать цель по смарт у нас платформу онлайн обучения с курсами, тестами, уведомлениями и аналитикой, привлекая 1.000 пользователей и 100 курсов в первый год. И основной функционал представлен у вас непосредственно на слайде.
Соответственно, начнём мы первое с чего- это технологический стек, который мы будем использовать. База данных и проектирование будем использовать технологии Postgl PL PGSQL исуру. То есть проектируем реляционные базы данных, триггеры, DDL скрипты, настройка граф QL через хасуру, после чего у нас идёт разработка апи и интеграций через Rest app, graph QL, Open App, SwagerHub, где мы задокументируем нашу документацию, интегрируем Backendsbd и сделаем непосредственно HTML-формы, на которых мы как раз-таки отобразим наш фontт функционал, который у нас будет.
После у нас произойдёт внешняя интеграция и событийная архитектура, вебхуки, кавка, ребит. Соответственно, будет практика с технологиями телеграма. Платёжные формы мы реализуем на Яндекс-формах для того, чтобы, а, как раз-таки не задействовать настоящие платёжные формы, но при этом интеграция очень похожа между ними. И также настроим кавку Rabbit MQ. А потоковая обработка NoQL. Поговорим про Rabit MQ и Redis. Практика по QL или потоковая обработка данных через RIT MQ. И визуализируем наши данные с помощью как раз-таки Яндекс Data Lens, то есть создадим даш, анализируем и визуализируем а данные.
Первое, с чего стоит начать - это очертить границы нашего проекта. И границы нашего проекта мы очерчивать будем непосредственно с помощью диаграммы юзкейсов. Здесь у нас представлены преподаватель, студент, администратор. И у них будут следующие юзкейсы, исходя из нашей задачи. Преподаватель просматривает аналитику, создаёт курс, добавляет тесты, за может загрузить материалы. Студент непосредственно проходит курсы, сдаёт тесты и получает уведомления. А администратор может одобрить курс и проверить курс. Это непосредственно очерчивает функциональные границы нашего с вами проекта учебного, на котором мы рассматриваем данный курс.
И непосредственно далее мы можем сделать наложить функциональную проекцию на проекцию по данным, сложить их для того, чтобы убедиться, что у нас всё правильно и мы ничего не забыли. Соответственно, для этого мы используем диаграмму C4 уровень один, где у нас образовательная платформа, наши пользователи, студент, преподаватель и администратор. И также уже не забываем про различные сервисы, с которыми мы будем интегрироваться. Это почтовый сервис, Telegramбо и Яндекс Data Lens. Соответственно, эти сервисы, которые нам помогут отправлять уведомления, отправлять в Telegramбот события новые и Яндекс DataLe предоставлять данные для визуализации.
Далее мы раскроем с вами вот этот вот компонент непосредственно и посмотрим на а диаграмме уровня номер два, какие у нас компоненты здесь присутствуют. То есть у нас в образовательной платформе есть веб-интерфейс, есть на апе, есть фоновые задачи и есть база данных. Соответственно, вот таким образом организуется непосредственно работа а с данными и функциями. Мы их проверили взаимно друг на друга, поняли, что у нас всё здесь хорошо, то есть преподаватель может управлять функциями. Мы это не забыли на диаграмме. а с данными и не забыли на диаграмме непосредственно а функциональной диаграмме юзкейсов.
И далее мы можем приступить к созданию непосредственно нашей базы данных. Для того, чтобы создать нашу базу данных, мы будем использовать непосредственно а-а draw SQL, в котором мы пропишем непосредственно наши базы данных и после чего выгрузим это вот такой вот DDLрипt. У меня здесь представлены основные моменты, которые присутствуют в моём DDL скрипте. Здесь, конечно же, не полная его структура. Соответственно, здесь есть у меня таблица пользователей, курсы и модули. DDLрипt нужен для того, чтобы мы могли создать нашу базу данных.
После того, как мы создадим нашу базу данных, мы получим вот такую вот ERD, в которой у нас как раз-таки вот они присутствуют у нас курсы, да, там, например, пользователи, пользовательские активности, пользовательский прогресс, тест, резалты. а результаты тестирования, вопросы, ответы и так далее. То есть получаем непосредственно D.
И следующее, что нам нужно сделать - это непосредственно наполнить эту базу данных какими-то тестовыми данными. Эти тестовые данные мы генерим с помощью AI и непосредственно получаем DML скрипт, который будет выглядеть следующим образом. А здесь маленькие примеры основных непосредственно инсертов. То есть добавляем курсы, добавляем модули, добавляем темы, добавляем тесты и добавляем вопросыответы. Соответственно, таким образом получаем наполненную нашу базу данных, которая непосредственно представлена. Вот курсы у нас, которые, например, SQL для аналитиков, Python для обработки данных, визуализации дашборды, биоинструменты на практике и машинное обучение. И каждая из этих табличек, она наполнена предварительными данными.
На этом работу с базой данных мы временно заканчиваем и непосредственно переходим к нашему бэкэнду. Переходя к бэкэнпу, у нас появляются здесь вопросы. Что мы будем выбирать для того, чтобы взаимодействовать с нашей базой данных? У нас есть постг, которые сейчас вы только что видели, как мы создавали и есть хасура. Соответственно, если краткое сравнение приводить, постгре - это реляционная база данных, а redis - это inmemory, noql value storage, то есть она содержит ключ значения. И Хасура, авторгенератора граф QLI поверх PostGql. Postgre SQL используется для основного хранилища данных, таких как пользователи, курсы, тесты, результаты.С дис у нас будет использоваться для кэширования очереди задач хранения сессий и счётчиков, а также для результатов оплаты, потому что она достаточно быстрая. Алхара будет использоваться как быстрая и доступ к данным без написания бэкэн-кода.
Соответственно, постгq - это ядро данных. Например, студент прогресс по курсам результаты тестов - это постг SQL. Он очень удобный для аналитики SQL заплсов и сложных джейсонок. Соответственно, там будут храниться курсы преподавателей, а пользователей, прогрессы, результаты и так далее. В Редисе мы будем использовать его как супербыстрое inmemory хранилище. Использовать для каширования запросов, очередей, задач, временных данных и быстрых счётчиков. Также вот здесь вот можно привести такой пример, сколько студентов прошли курс сегодня или тест за 3 минуты назад. Это всё вопросы к редису будут. И Хасура - это граф QL без кода. Используется для создания REST граф QL доступа постглю.
И, например, нам нужно выводить список курсов и прогресс студента на фоне граф Qэ. Соответственно, для того, чтобы использовать Хасуру, мы подключаем нашу базу данных, которую мы видели, создавали на предыдущих этапах. В итоге у нас образуется база данных здесь. После чего мы пишем запрос получить, например, курсы, нажимаем на кнопочку выполнить и непосредственно получаем вот здесь вот список наших курсов, которые мы имеем, которые мы уже видели в нашей базе данных.
Далее мы переходим уже в создание поинта вот здесь вот. И делаем этот endpint таким, чтобы мы по запросу get могли получить список этих курсов. Помимо этого мы ещё делаем пермишены, то есть настраиваем а разрешение и для роли анонимус, да, в нашем случае, то есть роль, которая не авторизованный пользователь, позволяем делать селекты. Таким образом, мы получаем, что у нас может любой, вы даже сами можете сейчас попробовать зайти по этому энпоинту и непосредственно просмотреть список курсов, который хранится в этой базе данных.
После чего, когда мы написали, так сказать, ленивый к следующее, что мы делаем - это мы пишем front непосредственно backend. А фронт у нас состоит из непосредственно начинаем со странички главной а добро пожаловать на платформу, где будут перечислены курсы и непосредственно эээнд, который будет содержать непосредственно а нашу обработку. И при записи, а при запуске мы оказываемся на сервере 127001 5.000. Соответственно, а по этому адресу у нас получается вот такая вот платформочка с нашими курсами, которые у нас представлены.
Далее мы продолжаем расширять наши MVP тем, что мы добавляем и настраиваем Telegramбота. Здесь мы отправляем сообщение в Telegram бота для того, чтобы, а, протестировать вообще его работоспособность. Прикрепляем это к нашему Яндекс-Форме. И теперь тестируем через Яндекс-Формы новую заявку, например, да, для того, чтобы вас пользователи могли запрашивать, например, какие-то новые курсы или оставлять отзывы. Соответственно, проверяем, что в Telegramбот доходит эта заявка, и в Яндекс-форме непосредственно указываем, по какому урлу а что отправлять и куда отправлять. Соответственно, также помимо этого добавляем Webhook. Обратите внимание, что здесь мы обращаемся к Хасуре А. Соответственно, когда Хасура получает вот этот вот а запрос, она делает webхhook и отправляет в Telegramбота информацию по новой заявке.
После чего делаем оплату, настраиваем оплату через ready. А, то есть вот здесь вот мы используем upstж для того, чтобы как раз-таки создать формочку. Делаем постзапрос. И помимо того, что мы это публикуем в рейдисе, мы ещё и публикуем это дополнительно в PostGSQL на долговременное хранение. Соответственно, а помимо того, что долговременное хранение у нас здесь, мы ещё можем сделать автоматическое обновление статуса заказа, то есть сделать триггерную функцию, которая будет выглядеть следующим образом. То есть функция для обновления статуса заказа. функция триггера на вставку в payment и сам триггер. Что это будет значить и как это будет работать? Когда у нас происходит оплата, оплата фиксируется непосредственно в нашем с вами а курсе, да? То есть, что оплата и передаётся в другую табличку, где у нас а непосредственно студенты и курсы связаны. И там эта информация уже выводится как то, что а у нас оплаченный ордер. Соответственно, мы присваиваем другой а статус, тем самым даём доступ к нашему курсу не просто в табличке проплат, что у нас появилась проплата, а также добавляем курсу, а пользователя, чтобы он мог его проходить.
Соответственно, помимо этого настраиваем уведомление на почту. Вот здесь у меня тестовое письмо, отправленное через SMTP. Аа, соответственно, здесь мы, а, добавляем это всё в момент оплаты для того, чтобы у нас также уходила информация на почту, что мы оплатили какой-то курс.
И после чего создаём свой instance в rбиit MQU в очереди в брокере событий для того, чтобы у нас была многопоточная обработка данных. Здесь у меня есть несколько ребитов и один неребит. Соответственно, создаём instance для того, чтобы мы могли принимать с вами какие-то данные, например, про а тот же заказ новых курсов. Соответственно, создаём обменник, который у нас будет фанаутом, то есть он будет фиксировать все, а, непосредственно очереди. Создаём очередь, в которой у нас будут псыпаться наши сообщения. И после чего мы с вами делаем следующее. Аа, мы, а, делаем скрипт, тестируем отправку сообщения в Rabit MQ. что у нас появился ордер с оплатой такой-то в нашу очередь такую-то. Тестируем это. И после того, как у нас тест сработал, проверяем, что сообщение приходит в наш брокер сообщений.
После чего добавляем Яндекс-форму, чтобы это было не через Посман, как сейчас это выглядит, да, а чтобы это всё отправлялась, а, так сказать, не ручками, а непосредственно клиентом. И потом мы после всего этого, когда организовали непосредственно а работу с брокером, прописали в сервере дополнительную информацию, и теперь у нас брокера сообщений. Сообщения забираются на наш сервер, обновляется база данных по триггеру, и всё это друг с другом связано, работает.
Мы делаем следующую вещь. Мы подключаем нашу BI-систему. В нашем случае это data lens. Соответственно, здесь выбираем постгре SQL, на котором мы работали. Указываем необходимые настройки, которые здесь есть. После чего создаём QLчарты с помощью вот таких вот запросов. Да, в данном случае у меня сколько людей зарегистрировалось, сколько из них записалось на курс, сколько завершили модуль и сколько сдали итоговый тест. Вот такие вот данные. представлены.
И когда мы сделали QR-чаты для всех, а, интересных нам бизнесовых метрик, мы создаём дашборд, а, и смотрим статистику по основным ключевым метрикам. В нашем случае это воронка вовлечение, динамика активности по дате, популярность контента, популярность курса топ по записям, то есть на какой курс сколько людей записываются. успеваемость топ-10 учеников. И также помимо этого смотрим статистику, динамику записей на курс по дням и топ-10 студентов по завершённым модулям. Соответственно, тоже вот такие вот красивые диаграммки с помощью QL-чартов строим для того, чтобы проанализировать эту статистику и сделать какие-то выводы.
А, соответственно, что у нас получилось? То есть у нас получилось, что мы с вами проговорили от проектирования архитектуры, то есть от C4 и UML диаграммы юзкейсов, проговорили про реализацию базы данных, реализовали внутреннюю интеграцию через Хасуру, реализовали внешнюю интеграцию с помощью бэкэнда, а далее была потоковая интеграция Noql Rabbit для того, чтобы как раз-таки проводить оплаты и также для того, чтобы у нас с вами, а, получается, когда, а, на форуме проходила оплата, отправлялся в instance брокеer сообщение, это сообщение забиралось, когда освободится сервер, и непосредственно формировалась, а, запись о том, что у нас непосредственно аа новая оплата, которая тригерит функцию в нашей постгре на то, чтобы дать курсу доступ. И после чего мы сделали визуализацию а дашдов для анализа данных, чтобы понимать, что у нас происходит на курсе.
Обо всём этом я подробнее рассказываю непосредственно на онлайн-курсе Архитектура IT-решений, проектирования и реализации MVP. И ближайший поток будет 12 тире 30 мая, где мы за 3 недели как раз-таки дойдём от вашей идеи до непосредственной реализации MVP.
Так, всем спасибо большое. Давайте начнём с вопросов. Угу.
Мира, спасибо большое за интересный доклад. У нас уже появилось несколько вопросов в чате. А начну с самых первых. По презентации кажется, что технологический стек выбран сразу после описания требований. На каком моменте в реальном проекте следует выбирать стек?
Так, смотрите, стек мы выбираем как раз-таки после того, как делаем функциональное проектирование. После функционального проектирования у нас начинается техническое проектирование. И, соответственно, после технического проектирования, а, непосредственно у нас с вами будет, а, определён уже ограничения. И после определения ограничений мы можем выбрать стек непосредственно технологий, на которых пишем. Если мы пишем MVP, то зачастую мы ограничиваемся какими-то песочницами, что очень свойственно для MVP, потому что нам в MVP важно протестировать какую-то идею.
Спасибо, Алексей. Если Мира не до конца ответила на ваш вопрос, будем ждать уточняющих вопросов. Перехожу к следующему. Елена спрашивает: "Почему на диаграмме C4L1 нет сервиса платёжных форм?"
Угу. А так на диаграмме C4 уровня один и нет платёжных форм по той причине, что мы непосредственно используем а Яндекс-формы для платёжных форм. То есть мы будем использовать их как часть нашей системы, соответственно, саму платёжную систему, так как нет возможности попробовать, э, на курсе протестировать платёжные системы, так как нужно подключать определённые права и реально оплачивать, соответственно, это немножко трудоёмко, поэтому мы имитируем работу с платёжными формами. через а яндексформы.
Спасибо. Следующий вопрос. Почему бизнес-логику обрабатывает контейнер с на с названием RESИ? По какому принципу выбрали название для контейнеров? По какому принципу выбирали название для контейнеров? Непосредственно по принципу того, что там будет внутри заложено. То есть непосредственно будет это обработка или SP. То есть в данном случае у нас. Угу. Так.
Следующий вопрос от Максима. В каком инструменте рисовали ERD? В каком инструменте рисовали ERD? Изначально D было прорисована непосредственно в дроql, после чего выгружен DDLрипт. А на DDL скрипте, который был показан на слайде, после него следовал непосредственно РДИшка. Сейчас покажу её ещё раз. Это ERD непосредственно из Супайса. Оно там прорисовывается самостоятельно после того, как вы вставляете вот этот скрипт непосредственно в Supbase. Там можно же и посмотреть непосредственно вот этот вот вот эти таблички. Угу.
А следующий вопрос от Эвелины. Зачем столько хранилищ для такого маленького функционала выглядит дорого?
Да, это действительно выглядит дорого, но нам нужно, а, нам нужно непосредственно понять, как работать с разными типами хранилища, потому что на вашем MVP может быть непосредственно, а, разная реализация. И для того, чтобы показать, как работать с тем и другим, непосредственно, а, смотрим на граф QL, смотрим на дисмотрим на PostGSQL.
мира. От Рустама поступил вопрос по курсу. Чтобы пройти курс, нужно ли знать какой-то язык программирования?
А чтобы пройти курс, конечно, в идеале знать Python, но по факту а мы будем работать с непосредственно а курсором. Это что-то вроде чата GPT, который будет помогать вам писать. и как раз-таки разберёмся, как писать, а непосредственно с помощью него а ваше MVP. То есть от вас нужно будет базовая понимание. Угу. А Рустам, если будут ещё какие-то вопросы, обязательно пишите.
От Георгия быстро поступил вопрос. Я правильно понимаю, что на курсе можно будет писать любой MVP?
Да, у нас есть непосредственно заложенные а проекты, которые вы можете взять себе за основу, если у вас нет реального MVP. Но если у вас есть своя идея, вы можете взять свою идею. Угу.
А также вопрос от Андрея. Подскажите, пожалуйста, что будет на курсе? Какой план обучения?
Непосредственно вот план обучения, который у нас будет. Угу. Да, примерно сегодня Мира прошлась по основным тезим. И если вам интересно, вы можете к нам присоединиться. У нас курс проходит достаточно часто. Да, в презентации будет доступна ссылка. не потеряете.
И вижу ещё вопрос последний. А всё, что вы показали - это работа архитектора ПО? Я немножко не понимаю этого вопроса. То есть прорабатывал ли это архитектор программного обеспечения?
Да, наверное, а хочется тут ответить на вопрос, то есть каждый, на каждом ли этапе работает архитектор ПО или нужно подключать каких-то там сторонних наших специалистов? Не на каждом этапе вот на визуализации данных уже не работает архитектор ПО, но при этом он присутствует, начиная от проектирования архитектуры и до последних, а, непосредственно шагов, которые мы прорабатывали.
Спасибо большое, Мира, за подробные ответы, в частности, по поводу нашего курса, по поводу содержания презентации. А я вижу, что всё-таки вопросы пока по затихают. Так или иначе, если у вас потом появятся вопросы, вы можете их записать в чате в группе в Телеграме. Мира там состоит, если что, на всё ответит. Уже, к сожалению, не в лай-формате, а в текстовом. Мира, я хочу тебя ещё раз поблагодарить за наш вебинар. А мне кажется, он получился очень ёмкий и информативный, и ты очень содержательно ответила на все наши вопросы нашей аудитории. Спасибо, что вы к нам сегодня подключились и будем рады видеть вас на курсах школы и также на вебинарах. Всем хорошего вечера.
Хорошего вечера.