Arquitetura
Como o app gerado se organiza por camadas e por backend.
Todo projeto Kasy segue a mesma arquitetura em camadas. O backend muda, a UI e os fluxos não.
Visão geral
Flutter (UI + Riverpod)
↓
Repositories (contratos)
↓
API por backend (Firebase / Supabase / REST)
↓
Servidor (Functions, Edge Functions ou sua API)| Camada | O que faz |
|---|---|
UI (lib/features/*/ui/) | Telas, widgets, zero lógica de negócio |
Notifiers (*_notifier.dart) | Estado, navegação, toasts, chamadas ao repo |
| Repositories | Contratos que escondem o backend |
| Backend | Firebase, Supabase ou API REST |
Três backends, mesma experiência
O Kasy mantém paridade de features nos três backends. A tela de login, paywall, push e admin são as mesmas. Só a camada de dados muda.
| Backend | Servidor |
|---|---|
| Firebase | Cloud Functions + Firestore rules |
| Supabase | Edge Functions + RLS |
| API REST | Endpoints que você implementa |
Onde mora cada coisa
router.dart
main.dart
| Pasta | Conteúdo |
|---|---|
lib/features/ | Uma pasta por feature (auth, onboarding, settings...) |
lib/core/ | Tema, navegação, config, utilitários |
lib/components/ | Design system (KasyButton, KasyCard...) |
lib/router.dart | Rotas globais (GoRouter) |
lib/environments.dart | Flags de feature e modo de auth |
Atualizado em 03/11/2026