Микрофронтенды: наш путь к более быстрому и гибкому сайту

имхо, он помог понять, что мы хотим и куда следует развивать продукт. какие ограничения для нас представляет монолит, готовы ли мы с ним мириться и соответствует ли он планам нашей трансформации из функциональных в продуктовые команды.
У АЕМ есть свои плюсы и минусы, а так же огромный функционал, который он предоставляет, но он не будет использован по тем или иным причинам.
SPA подход в АЕМ, стабилизировался намного позже начала реализации платформы микрофронтов. Да, в рамках эксперимента мы попробовали реализовать часть функционала на aem spa react. Но это не решение проблем. Просто перенос рендера со стороны htl на react и клиентский роутинг с обменом портянками json. Ведь билд и поставка так и оставались в зоне ответственности АЕМ (по крайней мере по тем рекомендациям со стороны adobe, которые существовали на тот момент). А это опять возвращает нас к длинным релизам и конфликту фич разных команд.
На сколько знаю, некоторое время назад, АЕМ таки смог реализовать Headless режим адекватный, но еще раз повторюсь, когда начинали разработку платформы микрофронтов, у АЕМ это было в зачаточном состоянии с весьма скудной документацией и необходимостью обновить версию АЕМ (что так же весьма не приятный процесс)

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