Перейти к основному содержимому

Подробное рассуждение о стеке на русском (proposal — detailed stack discussion)

Версия: 1.0 Дата: 27.04.2026 Статус: Открытый вопрос (на обсуждение, не утверждённое решение)

Назначение документа​

Этот документ — расширенная версия рассуждения о стеке на простом русском языке. Документ дополняет proposal-stack-roadmap-by-product-tier.md (формальная фаза-roadmap) и proposal-openapi-first-polyglot-codegen.md (codegen стратегия) — фокус здесь на обоснованиях простыми словами для команды, не имеющей глубокого инфраструктурного опыта.

Документ фиксирует:

  • что мы НЕ берём и почему (4 анти-варианта);
  • что мы берём и почему (5 каноничных слоёв);
  • честное обсуждение Vite vs Next.js для админки;
  • финальное рассуждение о том, когда выделять Vite SPA, а когда нет.

Документ не утверждает архитектурное решение. Решение по выбору между «всё в Next.js на фазе 1» vs «выделение Vite SPA с фазы 1» принимается на стадии 1 implementation baseline с участием future Tech Lead.

Что мы НЕ берём и почему​

1. «Делаем весь backend на Node.js / Deno»​

Идея: один язык везде — JavaScript/TypeScript на фронте и сервере. Команда меньше, переключаться не нужно, общие типы.

Почему отказываемся:

Tour Builder собирает тур из кусков от разных поставщиков, каждый раз пересчитывая цены. Когда пользователь двигает ползунок дат или меняет состав тура, система должна за миллисекунды опросить 30–50 поставщиков, собрать ответы, пересчитать саги, проверить наличие. Node.js однопоточный — он буквально не может делать много вычислений параллельно. Один тяжёлый запрос блокирует все остальные.

Поиск по 127 тысячам отелей с фильтрами, геолокацией, сортировкой по релевантности — то же самое. Node.js справится с малыми объёмами, но при первом крупном клиенте (Enterprise tier с гарантией 99.9% uptime) полезут таймауты.

И ещё: V8 (движок Node.js) периодически делает «уборку памяти» (garbage collection). На критических путях вроде платежа это может дать паузу в 200–500 мс. Для платежа это вечность.

Простой образ: Node.js — как один официант на ресторан. Пока он несёт тарелку одному столу, остальные ждут. Для лёгких запросов это нормально, для нагруженного платформенного backend — нет.

2. «Делаем всё на Go, фронт серверный из Go-шаблонов»​

Идея: Go быстрый, простой, один язык — пишем HTML прямо из Go-шаблонов, без всякого Next.js.

Почему отказываемся:

В travel-индустрии поисковая выдача Google — главный канал привлечения клиентов. Booking.com, Airbnb, Skyscanner получают 60–80% трафика из поиска. Для этого Google должен видеть содержимое страницы — конкретный отель, конкретные цены, конкретный город.

Go-шаблоны технически могут отдать готовый HTML, но разработка фронта на Go — это шаг назад на 10 лет. Нет горячей перезагрузки при разработке, нет компонентной модели, нет рич-интерактивности (вы не сделаете Tour Builder с drag-and-drop в Go-шаблонах). Найм фронтенд-разработчиков, готовых писать UI на Go — почти нулевой.

Современная веб-разработка живёт в JavaScript-экосистеме. Игнорировать это — значит писать всё с нуля, медленно, без библиотек, с маленьким пулом разработчиков.

Простой образ: Go-шаблоны — это как печатная машинка против ноутбука. Можно, но зачем.

3. «Админку и Tour Builder тоже делаем серверным рендерингом»​

Идея: раз Next.js хорошо для B2C, давайте всё на Next.js, включая админку и Tour Builder.

Почему отказываемся:

Серверный рендеринг (SSR) выгоден когда:

  • страницу нужно показать поисковикам;
  • пользователь редко взаимодействует — пришёл, посмотрел, ушёл.

Tour Builder — противоположность. Пользователь:

  • перетаскивает блоки тура мышкой;
  • меняет даты — цена пересчитывается мгновенно;
  • добавляет экскурсии — состав обновляется;
  • видит карту с маршрутом, кликает по точкам;
  • работает с туром 30–60 минут подряд.

При каждом клике делать новый запрос на сервер за HTML — это тормоза и лишняя сложность. Это классическое одностраничное приложение (SPA) — загрузил один раз, дальше всё работает в браузере, на сервер ходит только за данными.

Plus: админку не нужно индексировать в Google. Она за паролем. Весь смысл SSR (SEO) здесь не нужен.

Простой образ: SSR для админки — это как заказывать пиццу каждый раз когда хочется откусить кусок. Один раз привёз пиццу — ешь сколько хочешь, не вызывая курьера на каждый укус.

4. «Используем GraphQL вместо REST»​

Идея: GraphQL модный, гибкий, фронт сам выбирает что запрашивать.

Почему отказываемся:

GraphQL имеет смысл когда:

  • несколько фронтенд-команд работают параллельно;
  • разные клиенты (мобильное приложение, веб, партнёрский SDK) хотят разный набор полей;
  • backend-команда не может предугадать, что нужно фронтам.

У нас на старте:

  • одна фронтенд-команда;
  • два-три surface (B2C, админка, партнёрский UI), которые мы сами проектируем;
  • Tech Lead видит весь полный спектр запросов.

GraphQL добавляет:

  • сложный gateway-слой;
  • проблемы с кэшированием (REST кэшируется по URL автоматически, GraphQL — нет);
  • N+1 проблемы (когда один GraphQL-запрос превращается в 50 запросов в БД, если не делать DataLoader);
  • сложности с авторизацией на уровне полей;
  • больше узких специалистов в найме.

REST + OpenAPI даёт:

  • автоматически сгенерированные типы для фронта (через TS клиент);
  • автоматически сгенерированные клиенты для партнёров;
  • стандартное HTTP-кэширование;
  • понятный любому разработчику способ работы.

GraphQL — это инструмент для фазы 5+, когда команда выросла и реально появились разные frontend-команды с конфликтующими требованиями. Сейчас — преждевременно.

Простой образ: GraphQL — это шкаф с 50 ящиками для команды на 100 человек. Для команды на 10 — лишний.

Что мы берём и почему​

Слой 1. B2C-сайт (vitrip.store) → Next.js 15​

Что это: React-фреймворк, который умеет рендерить страницу на сервере перед отправкой пользователю.

Почему именно он:

Решение для SEO. Когда поисковик заходит на страницу /hotels?city=prague&priceMax=500&tab=reviews&offer=abc123, он получает готовый HTML с правильными ценами, отзывами, конкретным предложением. Не пустую страницу, которая «загружается потом» (как в обычных SPA). Поисковик индексирует, выдаёт в поиске, пользователи приходят.

Решение для глубоких ссылок (deep linking). Любая комбинация фильтров → отдельный URL → можно поделиться, забукмарить, открыть из истории, и страница покажет именно то, что было. Это критично для travel — пользователь сравнивает 5–10 отелей, открывает в новых вкладках, посылает другу ссылку. Если URL не отражает состояние — продукт сломан.

Решение для скорости. Next.js использует Server Components — серверный рендеринг тяжёлых частей (список отелей, карточки), и клиентскую интерактивность только там, где она нужна (фильтры, модалки). Это даёт быстрый первый показ страницы (важно для Google Core Web Vitals = ранжирование) и плавную интерактивность.

Решение для безопасности оплаты. Server Actions — это серверные функции, вызываемые с фронта. Платёжные ключи, токены, чувствительные данные никогда не попадают в браузер. Только серверная логика общается с PSP.

Это де-факто стандарт. Booking.com, Airbnb, Skyscanner, Vercel сами — всё на этом паттерне. Огромное сообщество, библиотеки, готовые решения для travel-кейсов.

Слой 2. Админка и Tour Builder → Vite + React (SPA)​

Что это: обычный одностраничный React-проект, без сервера в середине. Загрузился один раз, дальше работает в браузере.

Почему именно так:

Скорость интерактивности. Tour Builder с drag-and-drop работает в браузере без обращений на сервер. Перетащил блок — состояние тура обновилось мгновенно. Запросы на сервер идут только за данными (цена пересчитать, наличие проверить, сохранить).

Богатые UI-возможности. В SPA можно сделать:

  • сложные drag-and-drop интерфейсы;
  • анимации при перестановке элементов;
  • real-time обновления цен по WebSocket/SSE;
  • offline-режим (если связь моргнула — продолжаешь работать, потом синхронизируется);
  • сложные формы с условной валидацией.

В SSR это либо невозможно, либо очень громоздко.

Не нужен SEO. Админка и Tour Builder за паролем. Поисковикам не нужна. Значит весь overhead Next.js (серверный рендеринг, шаблоны, серверная инфраструктура) — лишний.

Vite быстрее в разработке. Hot Module Replacement (мгновенная перезагрузка изменений) в Vite быстрее, чем в Next.js. Когда инженер крутит UI Tour Builder, эта скорость экономит часы в день.

Общий дизайн с B2C. Дизайн-систему делаем как общий npm-пакет (@vitiana/ui). И Next.js (B2C), и Vite (админка) подключают этот пакет — кнопки, поля, стили выглядят одинаково. Брендинг единый, кодовая база разделена под свои задачи.

Слой 3. Партнёрский интерфейс → Next.js​

Что это: отдельный сайт или раздел для партнёров: документация, песочница, dashboard, биллинг.

Почему Next.js, а не Vite:

У партнёрского интерфейса двойная природа:

  • публичная часть (документация, маркетинг, лендинги для привлечения новых партнёров) — нужен SEO, нужен быстрый первый показ;
  • приватная часть (dashboard после логина) — обычный SPA-функционал.

Next.js поддерживает оба режима в одном приложении: маркетинговые страницы — статически сгенерированные (SSG), dashboard — клиентский рендеринг с авторизацией. Это самый эффективный путь, чем держать два разных проекта.

Слой 4. Backend → Go (основа), Rust (потом, для критических мест)​

Что это: Go — компилируемый язык, простой синтаксис, быстрый, специально создан Google для серверов. Rust — компилируемый язык с гарантиями безопасности памяти (нельзя случайно сломать память, что взломщики любят эксплуатировать).

Почему Go основа:

Многозадачность встроена. Go запускает тысячи параллельных задач (goroutines) на одном процессе. Когда поступает 1000 запросов одновременно — он обрабатывает 1000 одновременно. В Node.js — один за другим.

Не блокируется на сети. Когда Tour Builder опрашивает 50 поставщиков параллельно, Go-сервис делает это одновременно за 200 мс. Node.js последовательно — за 5 секунд. Пользователь видит разницу.

Меньше памяти. Go-приложение жрёт 50–100 МБ памяти на инстанс. Node.js — 200–500 МБ. На 100 инстансах разница — тысячи долларов в месяц на инфраструктуре.

Нет паузы на сборку мусора. Точнее, есть, но в Go это занимает 1–2 миллисекунды, в Node.js — 50–500 миллисекунд. Для платежа это критично.

Простой синтаксис. Senior-разработчик с другого языка осваивает Go за 2–3 недели. Rust — за 6–12 месяцев. На старте важна скорость найма.

Хороший пул в Восточной Европе. Go-разработчиков в Чехии, Польше, Украине достаточно. Не самый огромный пул как у Node.js, но и не дефицит.

Почему Rust добавляем позже (фаза 3):

Rust даёт ещё больше скорости и гарантии безопасности памяти. Для:

  • движка пересчёта цен Tour Builder в реальном времени;
  • координатора саг (когда нужно отменить серию операций при сбое одного шага);
  • движка поиска (обёртка над Elasticsearch с агрегацией от множества поставщиков);
  • внутреннего слоя обработки платежей (доп. слой защиты).

Но Rust сложен в найме. Senior Rust в Восточной Европе — редкость, обычно нужен с опытом из crypto/fintech. На старте, когда команда 4–8 человек, мы не можем позволить себе полгода ждать Rust-инженера.

Стратегия: на старте делаем всё на Go. На фазе 3, когда:

  • команда уже 15–25 человек, найм налажен;
  • есть метрики показывающие, что в Go-сервисе p99 задержка деградирует на нагрузке;
  • есть конкретный сервис, где Rust даёт измеримую выгоду;

— тогда нанимаем 1–2 Rust-инженера или переучиваем senior Go-инженера, и переписываем критические части. Не весь сервис — только горячие пути (например, ядро pricing-engine как Rust-библиотека, вызываемая из Go).

Слой 5. Машинное обучение → Python​

Почему именно для ML:

ML-индустрия живёт в Python. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face — всё это только в Python (или с Python как primary API). Data scientists, ML-инженеры обучены работать с Jupyter notebooks, pandas, numpy.

Попытка делать ML на Go или Rust — это писать с нуля то, чего в Python десятки готовых библиотек.

Но Python только для ML. Не для production-сервисов вне ML. Конкретно:

  • inference-сервисы (предсказание ranking, аномалий, recommendations) — FastAPI на Python;
  • training pipelines (обучение моделей) — Python;
  • утилиты для data science — Python;
  • бизнес-логика, API, платежи, бронирования — НЕ Python, а Go.

Python в production — медленный, GIL (Global Interpreter Lock) убивает многозадачность. Это инструмент только для своей ниши.

Главная идея простыми словами​

Платформа — это три разных продукта в одной коробке. У каждого свой оптимальный инструмент.

Что делаемЧем
Сайт для пользователей с поиском GoogleNext.js (быстрый показ, поисковики видят, ссылки работают)
Админка и Tour Builder для агентовVite + React SPA (богатая интерактивность, drag-and-drop)
Партнёрский интерфейс с документациейNext.js (SEO для маркетинга + dashboard)
Сервера, которые держат всю нагрузкуGo (быстрый, многозадачный, простой)
Особо критичные места по производительностиRust (потом, по фактическим метрикам)
Машинное обучениеPython (потому что вся ML-индустрия там)

Принцип: не заставлять один инструмент делать всё. Использовать тот, что лучше всего подходит под задачу.

На старте (фаза 1): Next.js на фронте + Go на бэке. Простой стек, два инструмента, быстрый старт. Найм понятный, инструменты зрелые, никаких экзотических решений.

На фазе 3: добавляем Vite SPA для админки (когда Tour Builder становится сложнее) и Rust в критические места (когда метрики покажут необходимость).

На фазе 4+: добавляем Python для ML (когда команда выросла до 25+ и появились ML-инженеры).

Это не монолит и не зоопарк. Это поэтапное усложнение по реальной потребности.

Уточняющий вопрос: «Ты говоришь что Next имеет и то и то, зачем Vite тогда?»​

Хороший вопрос. Действительно, Next.js умеет и SSR, и SPA-режим ('use client'). Технически весь продукт можно написать в одном Next.js-приложении.

Давай разложу честно — что Vite даёт сверх Next.js для админки и когда это окупается.

Что Next.js умеет делать SPA-образом​

В Next.js 15 App Router можно пометить компонент 'use client' — и тогда он рендерится в браузере как обычный React-компонент. Технически:

  • /admin/tour-builder маркируется как client component;
  • drag-and-drop, real-time pricing, состояние тура — всё работает в браузере;
  • Next.js просто отдаёт начальный HTML-каркас, дальше React работает как SPA.

Это работает. Многие компании так и делают. Это валидный путь.

Где Vite реально лучше​

Расскажу, где разница ощутимая, а где маркетинговая.

Реальные преимущества Vite для админки​

1. Скорость разработки (HMR).

Когда инженер крутит UI Tour Builder — добавил поле, поправил стиль, изменил логику — Vite перезагружает изменение за 50–200 мс. Next.js — за 1–3 секунды. На фазе активной разработки это десятки минут в день экономии.

Но это разница для одного человека на разработке. Когда команда 4–8 человек, в сумме это значимо. Когда команда 2 человека и Tour Builder в режиме поддержки — не критично.

2. Размер production-бандла.

Next.js тащит за собой инфраструктуру серверного рендеринга, даже если ты её не используешь. Это около 80–120 КБ overhead в JS-бандле. Для админки с авторизацией это не блокер (пользователь уже залогинился, готов ждать секунду).

Для B2C, где первый показ страницы — критичный момент конверсии, эти 80 КБ имеют значение. Для админки — нет.

3. Build-время.

Vite собирает админку за 5–10 секунд. Next.js — за 30–90 секунд (особенно с большой кодовой базой, потому что собирает и серверную часть тоже). На CI это влияет на скорость деплоя.

4. Простота ментальной модели.

В Next.js нужно постоянно держать в голове:

  • это server component или client component?
  • эта функция выполняется на сервере или в браузере?
  • может ли я тут использовать localStorage/window?
  • как сериализуются props между server и client?

Для админки, где всё равно всё клиентское, эти вопросы — лишний шум. В Vite SPA вопрос не возникает: всё работает в браузере, точка.

5. Routing с типизацией.

TanStack Router (стандартный выбор для Vite SPA) даёт типобезопасные маршруты с параметрами. Next.js App Router — file-based, без статической типизации параметров. Для сложной админки с десятками экранов и параметров типизация маршрутов реально помогает.

Где разница маркетинговая​

  • «SPA быстрее» — для админки за паролем не важно;
  • «Vite модный» — Next.js не менее модный;
  • «Next.js сложный» — он сложный для B2C, для админки разница невелика;
  • «Серверный рендеринг затратен» — для админки с малым числом одновременных пользователей это не нагрузка.

Честный ответ: можно ли делать всё в Next.js​

Да, можно. И это валидная стратегия. Вот её плюсы:

1. Один framework — одна команда учит одно. Не нужно знать и Next.js, и Vite, и TanStack Router. Все React-разработчики работают в одной экосистеме.

2. Один репозиторий, один деплой. Одно приложение, одна CI/CD пайплайна, одна инфраструктура.

3. Shared компоненты тривиальны. Не нужен npm package для дизайн-системы — компоненты лежат в той же кодовой базе, импортируются прямо.

4. Авторизация в одном месте. Сессия, middleware, защищённые маршруты — всё в одном Next.js, без сложностей с CORS между двумя приложениями.

5. Меньше инфраструктуры. Один веб-сервер, один CDN-конфиг, один домен с маршрутами / и /admin/*.

Когда выделять Vite, а когда не выделять​

Решение зависит от того, насколько сложной станет админка.

Оставить всё в Next.js, если:​

  • админка — формы и таблицы, без тяжёлой интерактивности;
  • Tour Builder — последовательные экраны (выбрал отель → выбрал даты → подтвердил), без drag-and-drop;
  • команда до 8 человек, нет смысла разделять кодовые базы;
  • ускорение HMR на 1–2 секунды не критично.

Выделять в Vite SPA, если:​

  • Tour Builder — реально сложный, с canvas-подобным интерфейсом, drag-and-drop по таймлайну тура, real-time pricing на каждом действии;
  • работа в админке — долгие сессии по 30–60 минут с постоянной интерактивностью;
  • админская команда отдельная от B2C-команды, и они хотят независимый цикл деплоев;
  • сложные специфические библиотеки (например, для редактора маршрутов на карте) проще интегрируются в чистый SPA.

Пересмотр рекомендации​

Я был слишком категоричен в proposal. Честная рекомендация:

Фаза 1 — всё в Next.js.

Один фреймворк, одна команда, одна кодовая база. / — B2C, /admin/* — админка с client components. Меньше инфраструктуры, быстрее старт.

Фаза 3 — пересмотр по реальной картине.

Когда Tour Builder уже работает в продакшне, появятся реальные данные:

  • сколько кода в админке (если 100 тысяч строк — отделять стоит, если 20 — нет);
  • какие конкретные ограничения мешают (если разработчики жалуются на HMR — это сигнал, если нет — нет);
  • сколько Tour Builder требует специфических библиотек (если интегрируется сложный canvas-редактор — Vite проще);
  • размер команды (если админская команда стала отдельной — отделение оправдано).

Решение «Vite SPA для админки» должно приниматься по фактическим триггерам, а не превентивно.

Итог простыми словами​

Я перегнул в proposal. Next.js может делать обе задачи. Он не оптимален для админки в нюансах (HMR медленнее, ментальная модель сложнее), но эти нюансы становятся значимыми только когда:

  • команда большая;
  • админка реально сложная;
  • разработчики дёргаются от мелких задержек.

На фазе 1 — один Next.js на всё. Это правильнее. Меньше движущихся частей, проще онбординг, быстрее старт.

Vite — это запасной выход, который мы держим в кармане на фазу 3 как опцию, если конкретные метрики покажут необходимость. Не базовая стратегия.

Уточнение позиции (после обратной связи): Vite сразу обоснован​

После обсуждения с владельцем платформы стало ясно, что изначальная категоричная рекомендация была верна — попытка смягчить во втором ответе была ошибочной. Расскажу почему именно у Vitiana Vite сразу окупается.

Почему именно у Vitiana Vite сразу окупается​

1. Tour Builder — не «обычная админка»​

Если бы админка была формами и таблицами (CRUD над тенантами, пользователями, настройками) — Next.js хватило бы. Но в Vitiana Tour Builder — это продукт первого ассортимента, не вспомогательная функция.

Согласно tour-builder-domain.md и tour-builder-operational-model.md, это:

  • множественные переезды между сегментами тура;
  • разное проживание по сегментам;
  • экскурсии, услуги, аренда транспорта;
  • saga-транзакции с компенсациями;
  • drift detection (когда композиция расходится с реальностью у поставщика);
  • партнёрский UI/SDK поверх той же логики (правило 00000 — Tour Builder доступен партнёрам как peer-функциональность).

Это canvas-подобный редактор маршрута, а не «список чекбоксов». Для такого Vite SPA — natural fit, не «опция через два года».

2. Партнёрский Tour Builder UI/SDK — это уже два приложения​

В clients.md зафиксированы 6 surfaces, два из которых — Surface 2 (Agency) и Surface 4 (Partner UI/SDK) — оба нуждаются в Tour Builder UI. Согласно правилу 00000, Tour Builder для партнёров — не «упрощённая копия», а полноценный peer.

Если делать в Next.js — получится одно из двух:

  • дублирование Tour Builder UI в B2C Next.js + партнёрском Next.js;
  • извлечение Tour Builder в отдельный package — что и приведёт к Vite SPA, только позже и с большей миграцией.

Если уже понимается, что Tour Builder будет переиспользоваться в нескольких контурах (agency + partner UI + потенциально white-label embeddable) — выделять как отдельный SPA package сразу правильнее. Иначе через год придётся вырезать его из Next.js, переписывать импорты, пересматривать сборку.

3. SDK для партнёров — это уже Vite-территория​

В api-as-product.md зафиксированы composition primitives — UI components, которые партнёры embedd в свой канал. Такие переиспользуемые компоненты пакуются как npm package. Vite специально для этого спроектирован (library mode, оптимизированный output bundle, простая публикация). Next.js для library packaging — неестественный.

Если знаешь, что будет SDK — у тебя по сути уже есть библиотечная сборка. Vite встаёт на это место без сопротивления.

4. Brain-bandwidth команды​

Когда команда 4–8 человек, главный ресурс — внимание инженеров. Next.js Server Components / Client Components / Server Actions / Route Handlers / middleware — это большая ментальная нагрузка. Каждый раз при добавлении кода нужно решать: «это server или client».

Для B2C это оправданно (выгода SEO + Core Web Vitals того стоит). Для админки — это постоянный налог на каждое изменение. Когда инженер пишет интерактивный компонент Tour Builder, ему не нужно думать про serialization boundaries и server context — ему нужно думать про state и UX. Vite даёт чистую SPA-модель: всё в браузере, никаких boundaries.

Этот налог суммируется. Через год это тысячи мелких решений, замедляющих команду.

5. CI/CD скорость​

Tour Builder будет иметь много визуальных тестов (Storybook + Playwright). Vite собирает за 5–10 секунд, Next.js — за 30–90 секунд. Когда CI запускает 50 визуальных тестов на каждом PR, разница в build-времени превращается в 15-минутные ожидания vs 3-минутные. Это влияет на ритм работы команды.

6. Технический долг разделения позже больнее​

Главный аргумент за выделение сразу: миграция Next.js → Vite через год — это переписать импорты во всех Tour Builder-файлах, пересмотреть обработку state, разорвать зависимости от Next.js-специфичных API (next/router, next/image, next/link). Это недели работы для senior-инженера.

Сделать сразу как отдельный Vite SPA — это договорённость в первую неделю проекта. Цена нулевая.

Принцип «развитие без деградации» (один из 5 архитектурных правил) явно говорит: не закладывать миграции, которые предсказуемо потребуются. Если Vite неизбежен на фазе 3 — значит он должен быть с фазы 1.

Каноничная картина​

@vitiana/ui                  ← дизайн-система (npm package)
  ↓ потребляется

@vitiana/tour-builder        ← Tour Builder как Vite library (npm package)
  ↓ потребляется
  ├─ B2C (Next.js) — embedded в proposal viewing
  ├─ Agency app (Vite SPA) — agency Tour Builder
  └─ Partner app (Vite SPA) — partner Tour Builder

vitiana-b2c (Next.js)        ← B2C сайт
vitiana-agency (Vite SPA)    ← admin/agency surface
vitiana-partner (Next.js)    ← партнёрский portal (маркетинг + auth-gated dashboard)

Tour Builder как отдельный package с самого начала — это и есть та архитектура, которая правильна для платформы с partner-grade SDK.

Финальный вывод по Vite vs Next.js​

Изначальная рекомендация верна: Vite SPA для admin/Tour Builder с фазы 1. Причины, которые делают это правильным в конкретном случае Vitiana, а не general principle:

  1. Tour Builder — core product, не вспомогательная админка;
  2. Tour Builder будет переиспользоваться в agency + partner + (возможно) embeddable;
  3. SDK для партнёров требует library packaging — это уже Vite territory;
  4. Ментальная нагрузка Next.js дуальной модели не оправдана для авторизованных surfaces;
  5. Миграция Next.js → Vite позже стоит больше, чем разделение сейчас;
  6. Принцип «развитие без деградации» это явно поддерживает.

Смягчение позиции во втором ответе было ошибкой — первоначальное чутьё владельца платформы было точнее.

Каноничный итог документа​

Этот документ фиксирует подробное рассуждение о стеке Vitiana на простом русском языке. Документ:

  • объясняет на примерах и образах, почему отказываемся от 4 анти-вариантов;
  • объясняет на примерах и образах, почему берём конкретный стек по 5 слоям;
  • честно обсуждает развилку Vite vs Next.js для админки;
  • фиксирует уточнённую позицию: Vite SPA для admin/Tour Builder с фазы 1 обоснован конкретикой Vitiana (Tour Builder как core, partner SDK, переиспользование в нескольких surfaces).

Финальная стек-картина для фазы 1:

СлойТехнология
B2C сайт (vitrip.store)Next.js 15
Админка / Agency / Tour BuilderVite + React SPA
Партнёрский portalNext.js (маркетинг + dashboard)
Tour Builder как переиспользуемыйVite library в npm package
Дизайн-системаnpm package (@vitiana/ui)
BackendGo primary
InfrastructureOVHcloud Managed Kubernetes

Расширения по фазам:

  • Фаза 3: Rust для critical paths по метрикам;
  • Фаза 4: Python для ML platform;
  • Фаза 5+: GraphQL gateway если frontend teams растут.

Документ остаётся открытым вопросом — финальное утверждение принимается на стадии 1 implementation baseline с участием future Tech Lead.

Связанная документация​

Связанные предложения (proposals)​

Опорные технологические документы​

Доменные документы​

Документы развития​

Архитектурные правила​