Pular para o conteúdo principal

Visão Geral da Arquitetura

Plataforma multi-tenant de apostas esportivas (Cactus Gaming). ~30 sites clientes, cada um com seu fork do template base.

Repositórios

RepoDescrição
front-cactus-coreSDK TypeScript — pacotes @cactus-agents/* (monorepo)
front-web-baseTemplate React Router v7 (SSR / Cloudflare Workers)
front-cactus-docsEsta documentação (Docusaurus)
front-web-{marca}Forks de marca (ex: front-web-vera-bet-br)
front-web-panelPainel admin (vault + deploys)
front-opsVault de envs + scripts de build/deploy

Stack

CamadaTecnologia
FrameworkReact Router v7 (SSR nativo no Cloudflare Workers)
Build/bundlerVite (via React Router v7)
StylingTailwind CSS v3 + CSS custom properties para tokens de tema por cliente
State (client)Zustand
State (server)React Router loaders
Data fetchingTanStack Query (cache client) + loaders (SSR)
Linter/formatterBiome (todos os repos)
TestesVitest + React Testing Library
Pre-commitHusky + lint-staged → biome check --write
CommitsConventional Commits (commitlint)
Package managerpnpm (enforced)
Node>=20.14.0 (recomendado: 22.18.0)

Deploy

  • SSR via Cloudflare Workers (React Router v7)
  • Assets estáticos → Cloudflare R2
  • Workers: render (SSR + static) + api-proxy
  • Scripts de deploy → front-ops

Pacotes privados

  • GitHub Packages como registry privado
  • Token de leitura por cliente (acesso apenas a @cactus-agents/*, sem código-fonte)

Modelo de fork

O fork é uma cópia completa do front-web-base. O cliente tem liberdade total para personalizar: criar componentes, páginas, regras, redesenhar o tema inteiro.

Pontos rápidos de customização (já preparados no template):

  • app/config/theme.config.ts — paleta de cores
  • app/config/routes.config.ts — árvore de rotas
  • app/config/layout.config.ts — componente de layout

Mas o cliente não está limitado a esses arquivos. Pode modificar qualquer coisa no fork.

Única restrição: não alterar pacotes @cactus-agents/* diretamente — eles são dependências npm atualizáveis via pnpm update.

Decisões técnicas

DecisãoMotivo
Cookie JS-readable (não httpOnly)Token precisa ser lido no client para headers.
AuthService singleton client-sideUm único ApiClient pro browser, separado do SSR.
Zustand sem persist para authToken persiste via cookie, não localStorage. Store rehidratado no mount.
Token refresh 6h via pure functionsLógica testável isolada. Store chama checkTokenRefresh(callback).
Modais controlados por ZustandauthModal: 'login' | 'register' | null. Qualquer componente abre/fecha.
EnvProvider separado do BrandProviderclientEnv (API_BASE_URL etc.) precisa existir antes de qualquer chamada API client-side.
Fork = cópia completa + liberdade totalConfig files são atalhos rápidos, não limites. Cliente pode personalizar o que quiser.
Biome em vez de ESLintMais rápido, config única pra lint + format, sem plugins.