Основа, на которой можно строить.

Работа, которую повторяет каждый продукт

Новый продукт начинается с конкретной проблемы. Его первые недели часто выглядят гораздо менее конкретно: сессии, записи воркспейса, состояние подписки, фоновая работа и доставка почты. Эти части должны сотрудничать, прежде чем продукт сможет сделать что-то полезное, — каждая из них решённая проблема в абстрактном виде и интеграционный риск в конкретном.

supastack даёт этой повторяющейся работе дом. Веб-приложение Next.js и мобильное приложение Expo делят TypeScript-пакеты для инфраструктуры под ними. Цель — сделать эти границы достаточно понятными, чтобы продукт мог настраивать их, не наследуя чужую доменную модель.

Ни одна из частей не сложна сама по себе. Цена живёт в их координации — платёж, который должен стать правом доступа, сессия, которая должна стать областью воркспейса, задача, которая должна пережить закрытый ноутбук. Продукты редко падают на отсутствующей функции. Они падают на стыке.

Зачем строить это один раз, но правильно

Аргумент за общую инфраструктуру не в том, что работа ниже вас, — а в том, что повторяющаяся работа заслуживает быть сделанной один раз, тщательно. Граница воркспейса, хорошо реализованная в общем модуле, защищает каждый продукт, построенный на ней. Та же граница, импровизированная под каждый продукт, становится набором почти-попаданий, различающихся интересными и опасными способами.

Она также концентрирует поддержку. API провайдеров меняются, библиотеки аутентификации развиваются, семантика биллинга дрейфует. Когда эти изменения ложатся в одно место — документация модулей кита отслеживает их, — исправление распространяется вместо того, чтобы переизучаться в каждом проекте. А когда вы взвешиваете этот обмен для одного продукта, стартовый кит или с нуля применяет те же рассуждения к решению «купить или построить».

Общая инфраструктура концентрирует и ревью. Границу, живущую в одном месте, можно жёстко протестировать один раз — негативные случаи, повторные события, межтенантные попытки, — вместо надежды, что пять реализаций каждая попали правильно. Это часть причины, по которой кит инвестирует в свой набор тестов: поддерживать доверие к общему коду дешевле, чем заново заслуживать его в каждом проекте.

Дайте каждому модулю одну ответственность

Идентичность устанавливает, кто делает запрос. Воркспейсы определяют, к каким записям этот человек может обращаться. Биллинг фиксирует состояние платежа, а права доступа отвечают, доступна ли возможность. Разделение этих забот не даёт успешному редиректу оплаты стать решением об авторизации.

Та же дисциплина применяется к фоновой работе. Общий контракт JobRunner обещает enqueue, status и cancel. Trigger.dev владеет поведением workflow. Маленький интерфейс ценен, когда его пределы видны; сокрытие повторов или планирования за общим методом сделало бы систему труднее для понимания.

Better Auth отвечает на идентичность. Postgres и Drizzle держат записи. Stripe или Lemon Squeezy сообщают состояние платежа. Ни одному из них не поручается хитрить в чужой работе — стыки остаются достаточно узкими, чтобы рассуждать о них, — а основа надёжна ровно настолько, насколько надёжны её стыки.

Оставьте место для продукта

Процесс поиска клиентов, редактор документов и исследовательский ассистент могут использовать одни и те же модули идентичности и биллинга. Их записи, язык и процессы всё равно различны. Продуктовая логика принадлежит коду потребляющего продукта, а конфигурация связывает её с основой.

Это разделение — ещё и практическое решение о поддержке. Исправление изоляции воркспейса должно быть переиспользуемым. Изменение того, как один продукт оценивает клиента, не должно становиться новым требованием для каждого другого продукта.

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

Начните с одного полного потока

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

Локальная и продакшен-приёмка отвечают на разные вопросы. Проходящий локальный тест устанавливает поведение приложения в контролируемых условиях. Реальная персистентность аутентификации, доставка провайдеров, развёртывание и поведение устройств всё ещё нуждаются в собственной проверке. Держите это различие видимым по мере роста продукта.

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

Вопросы, стоящие за подходом

Несколько вопросов лежат под этим подходом, и на них стоит ответить прямо.

• supastack — шаблон или фреймворк? — Основа из модулей с контрактами между ними. Продуктовый код живёт вне Starter Core и подключается через конфигурацию, так что платформа может обновляться без форка ваших функций.
• Не сделает ли общая инфраструктура продукты одинаковыми? — Общей является только обвязка. Записи, процессы и язык остаются в кодовой базе продукта — части, которые клиенты реально видят, остаются вашими.
• Где начинается собственный код продукта? — С записей и процессов, которые есть только у него. Основа аутентифицирует пользователя и ограничивает данные; она не знает, что такое лид.
• Зачем монорепозиторий? — Чтобы web-, mobile- и desktop-приложения менялись вместе с пакетами под ними: одна система типов, одни тестовые ворота, никакого дрейфа между репозиториями.
• Что если мне нужно только веб-приложение? — Основа — это покупка; mobile и desktop — поверхности, которые можно принять или игнорировать. Ничто не заставляет вас поставлять приложение, которое вам не нужно.