Евгений Лабутин - Чистая архитектура и как она помогает строить микросервисы и микрофронтенды
2023 ж. 8 Қаз.
8 035 Рет қаралды
Ближайшая конференция - HolyJS 2024 Autumn, 6 ноября (Online), 12-13 ноября, Санкт-Петербург
- -
Спикер рассказывает, как применяя подходы чистой архитектуры можно построить огромное веб-приложение и при этом не запутаться в элементах логики.
Показаны примеры приложений, которые спикер уже реализовал. Он также делится библиотеками, которые позволяют использовать ЧА в своих проектах на функциональных компонентах с хуками. Вы узнаете, как сделать ваш проект еще масштабнее, не прибегая к построению огромных приложений, а делая большое количество маленьких. Также разбираемся, как во всем этом помогает ЧА.
Ссылка на доклад:
labeg.github.io/presentation-...
#js #architecture
Чуваку просто так понравился первый ангуляр, что половину концепций из него он перетащил реакт (Controllers/Servers/DI). Велосипед с аннотациями по сериализации/десериализации JSON можно полностью заменить на mobx-state-tree.
Большое спасибо за доклад! Решил поделиться мыслями на счет услышанного. Начнем с плюсов: + Еще один доклад про чистую архитектуру. Тем более с точки зрения фронтенда. Это хорошо, потому что материалов, объясняющих "на пальцах" что это такое совсем немного. А в сфере фронтенда это вообще редкий зверь. Особенно с рабочими примерами, а не на бумаге + Помимо основной темы, Евгений касается около тематических вопрос (di, ddd (модельки), микрофронты) и быстро рассказывает, что это такое. Это хорошо для начинающих, так как подобные вбросы действуют как якоря для информации. А теперь по минуса: - Евгений, как и почти 90% авторов материалов про чистую архитектуру, начинает с затравки о том, что этот подход/методология/архитектура позволяет быстро менять фреймворки, библиотеки и так далее. Этот миф очень легко развеять, просто попробуйте написать приложение сначала на vue, а потом переведите его на react. Про Ангуляр я молчу. Да и где-то ближе к середине докладчик говорит о том, что с Ангуляра вы так просто не съедете, его трудно заменить, если не делать это полностью. Даже на беке сменить orm или базу иногда не из простых задач. Конечно, с ЧА это будет проще. - Было бы прекрасно, если был бы заранее заготовлен пример кода (необязательно помещать на слайды) с логикой посложнее, чем банальный todo app. Потому что на бумаге подход простой, а при попытке вникнуть и применить у себя могут возникать вопросы, которые не освещены докладом. Или о которых доклад умалчивает. - Евгений, если вы будете читать этот комментарий, убедительная просьба, дышите носом. Резкие и громкие вздохи ртом режут слух.
@mrerberg спасибо за отзыв! Про минусы: - Ангуляр на самом деле легко заменить на реакт при условии что в первом не использовался RxJS. Сам этой задачей к сожалению не занимался, но продумывал решение для коллег которые этим занимались. - Пример проекта на самом деле многие спрашивают, и внутри МТС он есть. А вот снаружи к сожалению нет. Я вижу что есть спрос, поэтому если появится свободное время то обязательно его реализую! - Да, на записи тоже это заметил. Но тяжело дышать носом когда в первые выходишь на полный зал, да еще и в главный, да еще и с такой серьезной темой, да еще и уложить 1,5 часовой доклад в 45 минут =) Постараюсь в следующих докладах учесть проблемы первых выступлений! =)
Очень крутой доклад, спасибо!
не зашлел доклат, перескажу книгу за 20минут и начал лить воду: мои беблиотеки, мои кейси, я юзаю валидатор я крутой, мать его мтс калькулятор, "преймущество подхода" - а про подход 0 слов)) называется угадай о чем я говорю
Чего блять? Ты жопой смотрел? Во первых, он сначала рассказал, какой он крутой, а уже потом начал рассказывать про чистую архитектуру. Посмотрел, послушал с удовольствием.
Спасибо за доклад! Как раз то что нужно было. Упорядочил в голове свои мысли по этому поводу и появились новые идеи.
Доклад шикарный. Слушал взахлёб ещё когда работал в МТС. Подход хороший и универсальный как швейцарский нож. Но... если придерживаться такого подхода, то легко пропустить сильные стороны фреймворка и даже иногда изобретать велосипед. Редко кто будет в одном проекте использовать несколько разных фреймворков, только если не будут менять один на другой. Мне больше нравится всю логику и состояние утащить на бэк, а на фронте оставить минимум. А вот на бэке можно нормально развернуть чистую архитектуру без привязки к фреймворку и даже языку.
Отличный доклад! На одном дыхании! Единственный минус, не были сказаны минусы данного подхода, без этого, как-будто, не очень объективно выглядит
Очень крутой доклад. тоже пока не понимаю как использовать все слои в (фсд + эффектор), за сериализацию и десериализацию спасибо. отделю окончательно у себя сервисы и репозитории, что частично и так по наитию было сделано.
Спасибо за высокую оценку! =)
Что-то тоже похожее старался делать, но без должного опыта конечно не получалось, после доклада в целом сложилась некоторая картинка в голове, как это надо, спасибо!
Не за что =) Можно начать с reca, дальше все своим ходом пойдет.
@@labeg под store уже был настроена pinia под NuxtJS, а под di настроил InversifyJS, но без декораторов, на Nux 3 какая-то проблема поддержки декораторов
Спасибо за доклад! Вопрос по поводу подключения микрофронтенда в основное приложение. В примере указан путь до js-ки микрофронтенда, но, в имени пути нет хеша. Как тогда будет обновляться статика? Браузер ведь ее кеширует)
@user-kc4jo6ik9z спасибо за отзыв! Дело в том что такой микрофронтенд обновляется независимо от хостового приложения. Фактически хостовое приложение ничего не знает о обновлении. Поэтому настройка происходит на стороне сервера микрофронтенда. Конкретно я раздаю статику через Nginx, а для корректного кеширования использую заголовки кеширования. Поэтому браузер выкачивает микросервис только один раз. На второй запрос сервис ответит что микрофонтенд не поменялся и тогда браузер будет использовать кешированную версию. А в случае если поменялся, то отдаст новую версию. Плюс чанки так же можно закешировать заголовками, что бы клиент даже запроса на них не посылал.
@@labeg понял, спасибо за ответ!
`reca` не работает. Проверял на next и vite react. Пример из readme :\
На NextJS работает. Причем как в легких проектах, как и в проектах проворачивающие миллиарды. Напишите пожалуйста что за ошибка у вас и я помогу найти решение. Vite - не работает по той причине что у него под капотом esbuild, он хоть и быстрый, но не имеет полной поддержки функциональности Typescript. В частности он не поддерживает рефлексию. В качестве решения можно сделать свой аналог vite из rollup + swc + postcss. Я так собираюсь микрофронтенды, работает исправно.
И что у нас получилось, говорит автор. Прочитав желтую книжку все равно не получилась чистая архитектура, это больше на MVC с репозиториями похоже. Нет ни слова про инварианты в сущностях, про юз кейсы, в чистой архитектуре, контроллер это бекенд часть, но никак не фронтнендная, на круге есть явный презентер, который и нужно использовать на фронтенде, в книжке еще есть ModelView С декораторами тоже все не так, сборка микрофронтов происходит независимо и нет возможности использовать декоратор, а тот пример что был показан с сервис локатором - один из вариантов, но автор изобрел свое решение которое не работает
Конечно за 45 минут минут нельзя рассказать про всю чистую архитектуру от начала и до конца. Но зато можно рассказать основы чистой архитектуры и как оно может быть устроено во фронтеде. А подробности изучать часами и неделями уже в профессиональной литературе. Если контроллер это чисто бекенд часть, то как вы объясните использование этого слова в десктопных WPF приложения, а также iOS приложениях из коробки? А так же десятки других фронтовых технологиях. Исключение только подходы mvvm и mvp. Например в андройде Activity реализует Presenter. Декораторы с рефлексей отлично работают в микросервисах. Потому что рефлексия генерируется в том же файле что и сам класс. В частностина прошлом проекте собирал микрофронтенды для партнернских продуктов для встраивания системы оплаты. А сейчас на проекте делаю миграцию с C# Razor проекта на NextJS через сборку NextJS страниц в микрофронтенды с последующим встраиванием в легаси код.
@@labeg Как вы реализуете DI в микрофронтах то ? при чем тут рефлексия когда сборка микрофронта проходит отдельно от хост приложения в котором определен DI контейнер ? Разделение можно сделать с помощью своих декораторов которые будут ссылаться на глобал объект и доставать оттуда при инициализации инстансы подкладывая их в конструктор, по другому это не работает и это паттерн называется сервис локатор Контроллер это чисто бэк часть и не как иначе, в книжке есть пример чистой архитектуры с примером где есть фронтовая часть, еще раз повторю и посмотрите внимательно на схемы которые давал автор книги, там для представления есть presenter и ViewModel, который отлично ложиться на чистую архитектуру и в андройд приложениях, там нет у них контроллера у тех авторов которые следуют книге а не своей интерпретации. Поэтому я считаю что этот доклад явно не про чистую архитектуру а про какую-то вашу задумку
@@labeg спасибо за шикарный доклад. Слушал с удовольствием и есть ощущение, что наконец то в голове сложилась некоторая картинка. Один мой коллега бывший, матерый C# разработчик реализовывал на фронте очень похожую архитектуру, тоже мастерил свой DI, собственную сериализацию данных. К сожалению, после его ухода, мне не хватило тогда опыта поддержать такую архитектуру (больше никого не было на проекте). Так что тут есть мнение, что для такой архитектуры требуется наличие главного разработчика, который будет следить за тем, чтобы у остальных было правильное понимание архитектуры и как её применять. Конечно же, собрать проект на react cra + redux toolkit по мануалам из ютюб будет гораздо проще. У меня есть вопрос относительно nestjs. Я фронтендер и сейчас потихоньку изучаю nest и было интересно слышать про этот фреймворк в докладе. Собственно вопрос, насколько реально реализовывать production-ready SaaS решения на nestjs? Насколько это зрелый на сегодняшний момент фреймворк? Какие у него могут быть узкие места и нерешенный проблемы? Еще раз огромное спасибо!
@@lorentzimys спасибо за отзыв! Фронтенд разработка усложняется с каждым годом. Каждый год создаются все более крупные и сложные веб приложения. Поэтом спрос на подходы ЧА будут только расти, появляться больше хорошо описанных и задокументированных библиотек на подходах ЧА. NestJS отличный фреймворк, особенно в связке с TypeORM. У меня было реализовано на нем несколько микросервисов, все работало стабильно и надежно. Каких либо ограничений я не почувствовал. Единственный слабый момент у NestJS это медленный, относительно C#, рантайм. Поэтому если я знаю что нужно делать что то серьезное то выбираю C#. А если что то простое, что надо быстро поднять, то NestJS.
все конечно замечательно, но нафиг оно мне надо, буду дальше использовать фсд
ладно
Чистая архитектура это не замена FSD, я совместил два подхода. По сути FSD нужен, чтобы организовать компоненты к единой методологии
Чистая архитектура строится на Слоистой архитектуре. ФСД это реализация слоистой архитектуры. Поэтому они друг другу не противоречат. В частности я использую ФСД для организации компонентов и при этом строю приложение по подходам чистой архитектуры.