ИМХО контракт, это данные, я пришел к этому. Те это просто интерфейс каким то данных. В моем случае я взял за контракт модель орм'ки. Те модель иp орм'ки шариться между бекендом и фронтом. И этот контракт соблюдается как на бекенде так и на фронте. в итоге получилось вот такое https://github.com/klerick/nestjs-json-api
Большинство апи запросов это простые выборки. Плюс вокруг этого можно построить что то типо генерации роутов. Или имплементация json-api ( https://github.com/ringcentral/nestjs-json-api) с валидацией и опирировать только сущностями.
Имхо после использования typeorm, Sequelize кажется каким то громоздким с точки срезения кода. Использовать Sequelize без обвертки в тайпскрипт достаточно неудобно, а последний раз когда пытался использовать Sequelize и тайпскрипт вылезали ошибки типов, возможно сейчас этого уже нет.
не всегда это возможно. и не из-за того что, тот кто проводит собес плохой. У нас политикой запрещено давать прямой фидбек кандидату. Только через HR'a
готовых Ui либ много, но чтоб они были одинаковые для всех фреймворков я пока знаю только один. А нужно чтоб не только выглядели одинаково компоненты, но нужно чтоб еще чтоб поведение было одинаковое. Я ниже написал, микрофрнтенд это скорей процесс, чем разработка. И этот процесс нужно будет воткнуть в текущую инфраструктуру. Начиная работы с репозиторием, версионирования модулей, инркементальный деплой, процесс сборки. Я все думаю описать все то, с чем я столкнулся и как это решал.
я не сколько не против микрофронта, а даже за, я к тому что в реальности достаточно сложно продвинуть. я сам сейчас именно этой задачей и занимаюсь, но тут скорей повезло с руководством. Проблема микрофрнтенда, это то что нет каких то бестпрактикс, нет готовый решений, тк микрофрнтенд, это скорей процесс, чем разработка. И вот тут начинаются проблемы, которые вот сейчас их решаю.
интересно что скажет бизнес, когда Вы придете и скажите, вот для того чтоб мы избавиться от вендор лока, нам нужна универсальная UI либа, и для этого нам нужно n-ое количество человека часов. Я бы с попкорном понаблюдал за этим)
Когда пишуться приложения, обычно происхоидт так, а давайте что нибудь сделаем посмотрим что будет, сделали, посмотрели. Что дальше?
Бизнес: Надо добавить фичу
Программист: Надо сделать рефаткоринг
Бизнес: Фича важнее.
и так по кругу.
я вас умоляю))) не всегда программист может сделать хорошо, даже если очень хочет. если руководство, мягко сказать, другого взгляда) Классика ведь, ты говоришь нужно сделать вот так, а тебе, давай сделаем тут костыль, тк нужно показать красивые графики релизов. Руководству важно, что бы была красивая картинка. А как там работает, ведь у руководства крутой мак.
то то я думал что все сервисы которыми я пользуюсь грузятся по несколько минут)
Я пришел к тому что на данный момент, продуктовые проекты, уже давно на скорость рендеринга забили. Главное чтоб красиво было)
Как вы заставили собираться виджеты в случае, что вендорные зависимости поставляет Core UI?
я написал свой сборщик, основаный на rollup и Angular CLI Builder API. Верне как написал, до сих пор вношу изменения:). Core Ui знает что нужно для виджетов. При сборке, пробегает по этим зависемостям и собирает ES модули и генерирует import map. Когда собираеться виджет или приложение, используется тоже rollup и то что в Core Ui прописаны как вендор, в приложениях помечаются как внешние и не добавляются в сборку.
Как вы тестируете виджеты/микрофронтенды по отдельности?
виджеты/микрофронтенды у нас атомарные единицы, которые могут работать по отдельности. те процесс разработки и отладки не как не связана с Core UI. Как обычное веб приложение. e2e тесты проходят так же по отдельности(вернее планируется так, еще не дошли до этого)
Какая у вас шина общения? Redux имеет прекрасный Devtools, к которому можно интегрировать любую другую библиотеку. Это очень интересная возможность, кстати.
Шина самописная, она простая, просто позволяет реализовать через нее три действия комманда/запрос/событие. Я решил отказаться от стейта как такого тк, тогда получаеться связаность, а мы от этого хотели уйти. Каждое приложения или виджет имеет свой стейт если нужно. и общается через шину с другими если нужно. Ну и шина позволяет замокать что то на уровне разработке.
Каким образом у вас реализован роутинг?
Core Ui написан на angular, с самописным matcher'ом, часть роутинга на нем, дальше подключается, тот который используется в приложении. Если одному приложению надо перейти в другое, это делается через CoreUI, через шину отправляется комманда. У нас договореность на странице может быть только одно приложение которое работает с роутингом. и так же мы не используем вложенность одного приложения в другое, хотя для этого есть все возможности. Чтоб не закопаться в зависимостях.
Особенности дев окружения? Может быть какие самописные плагины?
Мы используем nx.dev и в целом большинство проблем исчезли. Туда же подключили кастомный билдер, которые собирает приложения как ES модули, включает в модулю ресурсы нужные заворачивает в npm и публикует.
Холостые релизы бывают?
nx.dev позволяет запускать сборки только того кода которые были изменены.
Было много маленьких проблем которые решали похожу дела. Как пример как фиксировать релизную версию. На какой стороне, на стороне CI/CD или вручную. Или вот пришлось реакт собирать по своему, тк реакт только как UMD модуль.
Сейчас как раз занимаюсь подобным. От от ифреймов откозался сразу. В итоге обычные js модули которые грузятся через import и экспортируют набор функции, которые определены на уровне API, где рендерить приложение определяет то самое Core UI на основе роутинга или исходя из разметки(виджеты). Core UI предоставляет вендор зависимости. Модули собираются без этих зависимостей. Модули общаются через «шину», которая внутри себя имеет 3 сущности — команды, запросы и евенты. Когда Приложение ренедриться, оно может зарегистрировать свои команды события и евенты, и общаться с другими приложением через эту шину, выполнять команды, запросы, слушать евенты. Самая сложное во всем этом было(в порядке уменьшения сложности) это сборка модулей, и организация дев окружения, релиз и деплой.
Полифил непринятого стандарта — это стремно. Вебпак давно зарекомендовавший себя инструмент, так что автор прав, ни одна серьезная компания на импорт-мапы пока не подпишется.
Ну у Вас какие-то двойные стандарты:). В Вашем решении вы используете вебкомпоненты, которые, тоже не особо железобетонный стандарт. С теми же HTML импортами там много вопросов. Те вы используете полифил не принятого, до конца стандарта:)
Так же, когда не был принят стандарт es модулей, в коде его активно использовали, а потом пропускали через babel, и как то не особо, люди беспокоились, что это не принятый стандарт. По поводу поддержки импортов, буквально пол года назад, была только поддержка в Chrome canary с флагом, сейчас во всех Chrome'ах с флагом, так что думаю скоро будет работать и без флага. По поводу Webpack, он хорош себя зарекомендовал для сборки бандла приложения, когда все в одном. А вот для сборки модуля, тут вопрос, тк на данный момент(в 4ой версии) он не умеет выплевывать es модуль(или я так и не смог понять как настроить его на это%).
Крупные куски сжимаются лучше чем много мелких.
Честно, я в этом вопще не вижу какой либо проблемы, тк такого рода проекты, пишутся где количество кода, ресурсов, стилей измеряется мегобайтами, и экономия в несколько килобайт как не выглядит не очень. ИМХО Тут другой подход нужен, тот же HTTP2, сервер пуш, сервис воркер.
Вовсе нет. Хост разглашает, что у него есть, приложения — что нужно им и что есть у них, все это максимально развязано. В крайнем случае скачается несколько раз.
Ну тогда получаеться:
Module Federation — это набор утилит для вебпака которые включает в себя какое то описание модуля, со своими зависимостями, и сборка всего этого.
Тот же import map, это просто будущий стандарт который позволяет зарезолвить нейминг в импортах для es модулей. es модули это не только модули js кода, но в будущем это и html и css в тех же вебкомпонентах. Тогда получаеться, если были бы утилиты которые могли сгенерировать import map, предоставить информацию другим мини приложении о том что есть у них, все это вместе собрать, то получиться все тоже самое, только с поддержкой нативных технологий. И тогда, наверное, можно было сравнивать. Но чтоб все это реализовать, нужно сделать несколько больше, чем просто написать конфиг для вебпака.
В целом я понял вашу идею — это еще один вариант реализации микрофронтенда с таким же количеством вопросов к обсуждению, как и в десятке других решений, существующих на текущий момент. Спасибо за статью)
цитата Tobias Sokra, если честно больше похожа на выкрик, импорты плохо, а вот наша штука лучше. С модулями, начиная с requirejs было примерно так же, каждый раз был, вот те модули плохие, а наши лучше, в итоге имеем AMD, SystemJs, CommonJs и вот еще модули от вебпака. Если к импортам относиться так же, что они не будут использованы. То к вебпак модулям наверное так же надо:). Только разница, что es модули поддерживаются(будут поддерживаться в полном мере) нативно. Полифилы всегда используются. А если полифил еще и следует какому-то стандарту. То ИМХО лучше идти этим путем.
Еще добавлю отсутствие версионирования зависимостей
если использовать полифил то там не только css модули
повышенную нагрузку на сеть по кол-ву запросов и худшее сжатие
Использование es модулей подразумевает под собой использование http2, server push и тому подобное. нужно корректно настроить кеш, сервер пуш, etc.
худшее сжатие, вы про tree shaking? если так, то получаеться вам нужно каждый раз пересобирать, базовое приложение чтоб добавить нужные вендор зависимости, выпилить то что не нужно(если я правильно понял как работает Module Federation). То какой профит от мини фронтенда, если при релизи вроде бы как атомарного мини приложения, которая не должна аффектить все остально, нужно запускать всю сборку?
да читал, и решения засорять глобальную область видимость через сервисворкер так себе. Все можно было сделать проще используя тот же роллап с конфигом на несколько строк, и этот скрипт вызывать в postinstall. И будет реакт акктуальной версии с es модулями.
На мой взгляд, вся суть микрофронтенды это атомарность, в вашем случае получаеться аффектиться сборка основного приложения с зависимостями.
В вебе пытаются стандартизировать, модули, модуль-импорты, да, нет инструментов для разработки из коробки, но их и не будет, если идти по пути реакта который не может определиться как публиковать пакеты или вебпака, который в 4ой версии не умеет билдить в нативный es модуль. Раньше было куча браузеров который изобретал свой стандарт, сейчас браузеров меньше стандарт один, но тут разработчики, теперь каждый раз изобретают свой стандарт)
но, к счастью, есть и более хорошее решение: Webpack 5 Module Federation.
Зачем? Есть же нативные модули? есть import-maps, и полифил для него, которое позволит из внутреннего приложения загрузить и стили и ресурсы через import.meta.url. и зависимости разруливаются.
Писал) и за 5 лет работая в 3ех компаниях где реакт головного мозга, не увидел хотя бы одного проекта который написан на реакте хорошо) в итоге все превращается в огромный монолит в котором черт голову
сломает. Реакт хорошая библиотека, но в умелых руках, но из-за меньшего порога входа, большинство разработчиков которые пишут на нем понятие о архитекторе не имеют. Каждый инструмент хорош по своему. Но в большом проекте где много форм выбор в пользу ангуляра. Да ты будешь биться головой об стену из-за ограничения фреймворка но ты знаешь куда ты бьешься и где искать решение.
ИМХО контракт, это данные, я пришел к этому. Те это просто интерфейс каким то данных. В моем случае я взял за контракт модель орм'ки. Те модель иp орм'ки шариться между бекендом и фронтом. И этот контракт соблюдается как на бекенде так и на фронте. в итоге получилось вот такое https://github.com/klerick/nestjs-json-api
Вопрос, как совместить ангуляр роутер с реакт/vue/etc?)
без использования хештега для дочерний приложений, там еще те пляски с буном)
Большинство апи запросов это простые выборки. Плюс вокруг этого можно построить что то типо генерации роутов. Или имплементация json-api ( https://github.com/ringcentral/nestjs-json-api) с валидацией и опирировать только сущностями.
Имхо после использования typeorm, Sequelize кажется каким то громоздким с точки срезения кода. Использовать Sequelize без обвертки в тайпскрипт достаточно неудобно, а последний раз когда пытался использовать Sequelize и тайпскрипт вылезали ошибки типов, возможно сейчас этого уже нет.
Когда пишуться приложения, обычно происхоидт так, а давайте что нибудь сделаем посмотрим что будет, сделали, посмотрели. Что дальше?
Бизнес: Надо добавить фичу
Программист: Надо сделать рефаткоринг
Бизнес: Фича важнее.
и так по кругу.
Я пришел к тому что на данный момент, продуктовые проекты, уже давно на скорость рендеринга забили. Главное чтоб красиво было)
я написал свой сборщик, основаный на rollup и Angular CLI Builder API. Верне как написал, до сих пор вношу изменения:). Core Ui знает что нужно для виджетов. При сборке, пробегает по этим зависемостям и собирает ES модули и генерирует import map. Когда собираеться виджет или приложение, используется тоже rollup и то что в Core Ui прописаны как вендор, в приложениях помечаются как внешние и не добавляются в сборку.
виджеты/микрофронтенды у нас атомарные единицы, которые могут работать по отдельности. те процесс разработки и отладки не как не связана с Core UI. Как обычное веб приложение. e2e тесты проходят так же по отдельности(вернее планируется так, еще не дошли до этого)
Шина самописная, она простая, просто позволяет реализовать через нее три действия комманда/запрос/событие. Я решил отказаться от стейта как такого тк, тогда получаеться связаность, а мы от этого хотели уйти. Каждое приложения или виджет имеет свой стейт если нужно. и общается через шину с другими если нужно. Ну и шина позволяет замокать что то на уровне разработке.
Core Ui написан на angular, с самописным matcher'ом, часть роутинга на нем, дальше подключается, тот который используется в приложении. Если одному приложению надо перейти в другое, это делается через CoreUI, через шину отправляется комманда. У нас договореность на странице может быть только одно приложение которое работает с роутингом. и так же мы не используем вложенность одного приложения в другое, хотя для этого есть все возможности. Чтоб не закопаться в зависимостях.
Мы используем nx.dev и в целом большинство проблем исчезли. Туда же подключили кастомный билдер, которые собирает приложения как ES модули, включает в модулю ресурсы нужные заворачивает в npm и публикует.
nx.dev позволяет запускать сборки только того кода которые были изменены.
Было много маленьких проблем которые решали похожу дела. Как пример как фиксировать релизную версию. На какой стороне, на стороне CI/CD или вручную. Или вот пришлось реакт собирать по своему, тк реакт только как UMD модуль.
Ну у Вас какие-то двойные стандарты:). В Вашем решении вы используете вебкомпоненты, которые, тоже не особо железобетонный стандарт. С теми же HTML импортами там много вопросов. Те вы используете полифил не принятого, до конца стандарта:)
Так же, когда не был принят стандарт es модулей, в коде его активно использовали, а потом пропускали через babel, и как то не особо, люди беспокоились, что это не принятый стандарт. По поводу поддержки импортов, буквально пол года назад, была только поддержка в Chrome canary с флагом, сейчас во всех Chrome'ах с флагом, так что думаю скоро будет работать и без флага. По поводу Webpack, он хорош себя зарекомендовал для сборки бандла приложения, когда все в одном. А вот для сборки модуля, тут вопрос, тк на данный момент(в 4ой версии) он не умеет выплевывать es модуль(или я так и не смог понять как настроить его на это%).
Честно, я в этом вопще не вижу какой либо проблемы, тк такого рода проекты, пишутся где количество кода, ресурсов, стилей измеряется мегобайтами, и экономия в несколько килобайт как не выглядит не очень. ИМХО Тут другой подход нужен, тот же HTTP2, сервер пуш, сервис воркер.
Ну тогда получаеться:
Module Federation — это набор утилит для вебпака которые включает в себя какое то описание модуля, со своими зависимостями, и сборка всего этого.
Тот же import map, это просто будущий стандарт который позволяет зарезолвить нейминг в импортах для es модулей. es модули это не только модули js кода, но в будущем это и html и css в тех же вебкомпонентах. Тогда получаеться, если были бы утилиты которые могли сгенерировать import map, предоставить информацию другим мини приложении о том что есть у них, все это вместе собрать, то получиться все тоже самое, только с поддержкой нативных технологий. И тогда, наверное, можно было сравнивать. Но чтоб все это реализовать, нужно сделать несколько больше, чем просто написать конфиг для вебпака.
В целом я понял вашу идею — это еще один вариант реализации микрофронтенда с таким же количеством вопросов к обсуждению, как и в десятке других решений, существующих на текущий момент. Спасибо за статью)
цитата Tobias Sokra, если честно больше похожа на выкрик, импорты плохо, а вот наша штука лучше. С модулями, начиная с requirejs было примерно так же, каждый раз был, вот те модули плохие, а наши лучше, в итоге имеем AMD, SystemJs, CommonJs и вот еще модули от вебпака. Если к импортам относиться так же, что они не будут использованы. То к вебпак модулям наверное так же надо:). Только разница, что es модули поддерживаются(будут поддерживаться в полном мере) нативно. Полифилы всегда используются. А если полифил еще и следует какому-то стандарту. То ИМХО лучше идти этим путем.
import-map поддерживает scope
если использовать полифил то там не только css модули
Использование es модулей подразумевает под собой использование http2, server push и тому подобное. нужно корректно настроить кеш, сервер пуш, etc.
худшее сжатие, вы про tree shaking? если так, то получаеться вам нужно каждый раз пересобирать, базовое приложение чтоб добавить нужные вендор зависимости, выпилить то что не нужно(если я правильно понял как работает Module Federation). То какой профит от мини фронтенда, если при релизи вроде бы как атомарного мини приложения, которая не должна аффектить все остально, нужно запускать всю сборку?
да читал, и решения засорять глобальную область видимость через сервисворкер так себе. Все можно было сделать проще используя тот же роллап с конфигом на несколько строк, и этот скрипт вызывать в postinstall. И будет реакт акктуальной версии с es модулями.
На мой взгляд, вся суть микрофронтенды это атомарность, в вашем случае получаеться аффектиться сборка основного приложения с зависимостями.
В вебе пытаются стандартизировать, модули, модуль-импорты, да, нет инструментов для разработки из коробки, но их и не будет, если идти по пути реакта который не может определиться как публиковать пакеты или вебпака, который в 4ой версии не умеет билдить в нативный es модуль. Раньше было куча браузеров который изобретал свой стандарт, сейчас браузеров меньше стандарт один, но тут разработчики, теперь каждый раз изобретают свой стандарт)
Зачем? Есть же нативные модули? есть import-maps, и полифил для него, которое позволит из внутреннего приложения загрузить и стили и ресурсы через import.meta.url. и зависимости разруливаются.
Писал) и за 5 лет работая в 3ех компаниях где реакт головного мозга, не увидел хотя бы одного проекта который написан на реакте хорошо) в итоге все превращается в огромный монолит в котором черт голову
сломает. Реакт хорошая библиотека, но в умелых руках, но из-за меньшего порога входа, большинство разработчиков которые пишут на нем понятие о архитекторе не имеют. Каждый инструмент хорош по своему. Но в большом проекте где много форм выбор в пользу ангуляра. Да ты будешь биться головой об стену из-за ограничения фреймворка но ты знаешь куда ты бьешься и где искать решение.
поставить точку останова, не?
github.com/klerick/fs-socket-io