варианты развития проекта Portal платформы CoreTech

Текущее состояние

На данный момент портал представляет собой большой монорепозиторий, содержащий набор пакетов для одновременной разработки и внедрения компонентов в несколько продуктов.

Основные проблемы текущей архитектуры:

• Высокая связанность компонентов затрудняет работу с порталом
• Жесткая зависимость фронтенда от Strapi
• Необходимость фронтенд-разработчиков выполнять роль фулстек-специалистов
• Низкая производительность из-за больших размеров Transfer State в Next.js

Технологический задел

Все компоненты во всех продуктах основаны на headless-подходе. В Storybook реализованы на React все основные блоки:

• Слайдеры
• Формы логина и регистрации
• Всевозможные вспомогательные компоненты

Эти наработки стоит переиспользовать при переходе на новые технологические решения.

Вариант 1. Переезд на новый движок (Astro и PayloadCMS)

Этот вариант предполагает сохранение React и всех существующих headless-компонентов, но замену связующего фреймворка.

План:

• Замена Strapi на PayloadCMS
• Замена Next.js на Astro для фронтенд-части
• Сохранение и использование существующих React-компонентов из Storybook (ускорение процесса разработки)
• Решение проблемы производительности за счет механизма partial hydration в Astro
• Упрощение кастомизации CMS, так как PayloadCMS написан на NextJS и React
• Более простая работа с базой данных в PayloadCMS

Для реализации требуется оценка Андрея по срокам миграции данных в PayloadCMS и перевода фронтенда на Astro.

Вариант 2. Использование headless-компонентов независимо от портала

Подход ориентирован на максимально быструю сборку новых продуктов, но не позволит перевести на него текущие проекты.

Отличия:

• Использование только headless-компонентов из текущего проекта
• Сборка продуктов силами верстальщиков без жесткой привязки к Strapi
• Возможность разделения проекта на отдельные репозитории для каждого клиента
• Существенное упрощение поддержки конкретных продуктов
• Потеря гибкости общего платформенного решения
• Невозможность миграции существующих продуктов из-за их зависимости от Strapi

Вариант 3. Разработка нового фронтенда на Svelte

Радикальное переписать фронтенд на другом технологическом стеке.

Особенности решения:

• Использование Svelte совместно с Astro или SvelteKit
• Прямая работа фронтенда с API продукта
• Написание нового фронтенда фактически с нуля
• Отказ от текущих наработок в Storybook
• Высокие временные затраты на повторную реализацию существующих функций

Можно попробовать переиспольовать компоненты из существующего фронтенда, asto позволяет использования гибридный подход (Svelte + React), но увы нет практики примерния такого подхода в продакшене

Рекомендации

При наличии бюджета предпочтительным будет первый путь. Для реализации необходимо:

• Обсудить с Андреем техническую сложность миграции данных из Strapi в PayloadCMS
• Провести оценку времени на переход к связке Astro и PayloadCMS После получения эстимейтов, если они будут совместимы с жизнью - необходимо реализовать в команде структурные изменения, разделив роль архитектора и тимлида в команде.

Второй путь выглядит наименее перспективным - сложности с поддержкой текущих проектов никуда не уйдут. В итоге мы будем иметь и типовые проекты на портале и кастомные без.

Параллеьно с этим можно рассмотреть возможность запуска пилотного проекта на новом стеке с другой командой (используя Svelte и PayloadCMS).

estimations

Важно, это оценка, не коммитмент, она нужна для понимания соотношения сложности реализации каждого пути. В реальной жизни все пойдет не так, как планируется (кто-то заболеет, что-то пропустим в функциональных требованиях и т.п.).

Путь 1: миграция на PayloadCMS и Astro без изменений связанных с способом работы с бекендом - займет пол года силами 4-5 разработчиков.

Путь 2: создание новых продуктов без Strapi на базе текущих headless компонент - займет 2-3 месяца силами 2-3 разработчиков.

Путь 3: запуск пилотного проекта на новом стеке с другой командой (используя Svelte и PayloadCMS) - займет 3-4 месяца силами 2-3 разработчиков.