구축할 수 있는 기반.

모든 제품이 반복하는 작업

새 제품은 특정 문제에서 시작합니다. 첫 몇 주는 흔히 훨씬 덜 특정적으로 보입니다: 세션, 워크스페이스 레코드, 구독 상태, 백그라운드 작업, 이메일 전송. 이 부분들이 협력해야 제품이 유용한 일을 할 수 있습니다 — 각각은 추상적으로는 해결된 문제이지만 구체적으로는 통합 리스크입니다.

supastack은 그 반복되는 작업에 자리를 제공합니다. Next.js 웹 앱과 Expo 모바일 앱이 기반 인프라를 위한 TypeScript 패키지를 공유합니다. 목표는 제품이 다른 사람의 도메인 모델을 상속하지 않고 그 경계를 구성할 수 있을 만큼 이해하기 쉽게 만드는 것입니다.

각 조각은 분리해서 보면 어렵지 않습니다. 비용은 그것들의 조율에 있습니다 — 엔타이틀먼트가 되어야 하는 결제, 워크스페이스 범위가 되어야 하는 세션, 닫힌 노트북을 견뎌야 하는 작업. 제품은 빠진 기능으로는 거의 실패하지 않습니다. 접합부에서 실패합니다.

왜 한 번 제대로 만드는가

공유 인프라를 주장하는 이유는 그 작업이 당신에게 하찮아서가 아닙니다 — 반복되는 작업이 한 번 신중하게 이루어질 가치가 있기 때문입니다. 공유 모듈에 잘 구현된 워크스페이스 경계는 그 위에 만들어진 모든 제품을 보호합니다. 제품마다 즉흥된 같은 경계는 흥미롭고 위험한 방식으로 다른 아차 사고들의 집합이 됩니다.

유지보수도 집중시킵니다. 프로바이더 API는 바뀌고, 인증 라이브러리는 진화하고, 결제 의미는 표류합니다. 그 변경이 한 곳에 도착할 때 — 킷의 모듈 문서가 그것들을 추적합니다 — 수정이 프로젝트마다 다시 배워지는 대신 전파됩니다. 그리고 단일 제품에서 그 교환을 저울질할 때, 스타터 키트 vs 처음부터가 같은 추론을 구매 대 구축 결정에 적용합니다.

공유 인프라는 리뷰도 집중시킵니다. 한 곳에 있는 경계는 — 네거티브 사례, 재생된 이벤트, 테넌트 간 시도 — 다섯 개의 재구현이 각각 올바르기를 바라는 대신 한 번 강하게 테스트될 수 있습니다. 그것이 킷이 테스트 스위트에 투자하는 이유의 일부입니다: 공유 코드에 대한 신뢰를 유지하는 것이 프로젝트마다 다시 얻는 것보다 쌉니다.

각 모듈에 하나의 책임을

신원은 누가 요청했는지를 확립합니다. 워크스페이스는 그 사람이 어떤 레코드에 도달할 수 있는지를 결정합니다. 결제는 결제 상태를 기록하고, 권한은 기능이 사용 가능한지 답합니다. 이러한 관심사를 분리해 두면 성공한 결제 리디렉션이 인가 결정이 되는 것을 막을 수 있습니다.

같은 원칙이 백그라운드 작업에 적용됩니다. 공유 JobRunner 계약은 enqueue, status, cancel을 약속합니다. Trigger.dev가 워크플로 동작을 소유합니다. 작은 인터페이스는 한계가 보일 때 가치가 있습니다. 재시도나 스케줄링을 일반 메서드 뒤에 숨기면 시스템을 추론하기 어려워집니다.

Better Auth가 신원에 답합니다. Postgres와 Drizzle이 레코드를 보유합니다. Stripe이나 Lemon Squeezy가 결제 상태를 보고합니다. 어느 것도 다른 모듈의 일에 똑똑해지라고 요구받지 않습니다 — 접합부는 추론할 수 있을 만큼 좁게 유지됩니다 — 그리고 기반은 그 접합부만큼만 신뢰할 수 있습니다.

제품을 위한 여지를 남기세요

리드 발굴 플로, 문서 편집기, 리서치 어시스턴트는 같은 신원 및 결제 모듈을 사용할 수 있습니다. 그들의 레코드, 언어, 워크플로는 서로 다릅니다. 제품 고유 로직은 소비 코드베이스에 속하며, 기반에 연결하는 구성과 함께합니다.

그 분리는 실용적인 유지보수 결정이기도 합니다. 워크스페이스 격리에 대한 수정은 재사용 가능해야 합니다. 한 제품이 리드를 평가하는 방식의 변경이 다른 모든 제품의 새 요구 사항이 되어서는 안 됩니다.

그것이 기반과 테마의 차이입니다. 테마는 유지하거나 교체할 겉모습을 줍니다. 기반은 제품이 우회하는 대신 그 위에 세우는, 하중을 지는 결정 — 누가 신원을 소유하는지, 레코드가 어떻게 범위 지정되는지, 결제가 어디서 액세스가 되는지 — 를 줍니다. 프로젝트 구조 가이드는 하나가 끝나고 다른 하나가 시작하는 곳을 보여줍니다.

하나의 완전한 플로로 시작하세요

로컬 참조 플로로 시작하세요: 로그인하고, 액세스를 검사하고, 작업을 제출하고, 결과를 읽으세요. fake 및 로컬 어댑터로 결정적 테스트가 프로바이더에 대한 유료 요청 없이 경로를 실행할 수 있습니다 — 5분 퀵스타트가 끝까지 실행합니다. 그런 다음 제품이 실제로 필요로 하는 프로덕션 통합을 구성하세요.

로컬 수용과 프로덕션 수용은 다른 질문에 답합니다. 통과한 로컬 테스트는 통제된 조건에서 애플리케이션 동작을 확립합니다. 실제 인증 영속화, 프로바이더 전송, 배포, 디바이스 동작은 여전히 자체 검증이 필요합니다. 제품이 성장함에 따라 그 구분을 보이게 유지하세요.

기반은 천천히 그 이름을 얻습니다: 첫 번째보다 빠르게 출시하는 두 번째 제품에서, 그리고 다섯 개의 코드베이스 대신 하나의 모듈을 고치는 유지보수의 날에서. 그것이 supastack 뒤의 베팅입니다 — 그리고 각 모듈이 유지되는 기준입니다.

이 접근 뒤의 질문들

이 접근 아래에는 몇 가지 질문이 있으며, 솔직하게 답할 가치가 있습니다.

• supastack은 템플릿인가요, 프레임워크인가요? — 사이에 계약이 있는 모듈들의 기반입니다. 제품 코드는 Starter Core 밖에 살고 구성을 통해 연결되므로, 플랫폼이 당신의 기능을 포크하지 않고 업데이트될 수 있습니다.
• 공유 인프라가 제품을 평범하게 만들지 않나요? — 배관만 공유됩니다. 레코드, 워크플로, 언어는 제품 코드베이스에 남습니다 — 고객이 실제로 볼 수 있는 부분은 당신의 것으로 남습니다.
• 제품 고유 코드는 어디서 시작하나요? — 그것만이 가진 레코드와 워크플로에서. 기반은 사용자를 인증하고 데이터를 범위 지정할 뿐, 리드가 무엇인지는 모릅니다.
• 왜 모노레포인가요? — 웹, 모바일, 데스크톱 앱이 그 아래 패키지와 함께 바뀌도록: 하나의 타입 시스템, 하나의 테스트 게이트, 리포지토리 간 표류 없음.
• 웹 앱만 필요하면요? — 기반이 구매 대상입니다. 모바일과 데스크톱은 채택하거나 무시할 표면입니다. 필요 없는 앱을 출시하라고 강요하는 것은 없습니다.