projetos / Ativo — MVP em desenvolvimento
GymFlow
Plataforma de acompanhamento de treino — frontend Next.js com RSC sobre uma API NestJS + Apollo GraphQL, Prisma e PostgreSQL.
- Next.js (App Router)
- React Server Components
- NestJS
- Apollo GraphQL
- Prisma
- PostgreSQL (Supabase)
- pnpm
Visão geral
GymFlow é uma plataforma de acompanhamento de treino: cria treinos a partir de uma biblioteca de exercícios, executa-os como sessões com registro de peso e repetições por série e revisa agenda, progresso e planos em um workspace desktop dedicado. O fluxo mobile fica concentrado em registrar uma sessão ao vivo; o desktop é o lugar para preparar blocos de treino e entender o panorama maior. Iniciado em fevereiro de 2026, o projeto também funciona como uma implementação de referência de uma stack específica — Next.js App Router com React Server Components no frontend, NestJS com Apollo GraphQL no backend e Prisma sobre PostgreSQL.
É um MVP em desenvolvimento ativo, e esta página deixa isso claro. A arquitetura está definida e documentada com diagramas mermaid no README, a integração com banco está em andamento e autenticação JWT própria é o próximo marco. O repositório é público: o código pode ser lido hoje, ainda em construção.
Demonstração ao vivo
Do início ao fim de um treino
app mobile responsivo
Arquitetura
O sistema é API-first: o backend NestJS é a única fonte de verdade, e cada cliente consome a mesma API Apollo GraphQL. O app web usa Next.js App Router com React Server Components buscando dados por um cliente GraphQL. GraphQL foi escolhido em vez de REST especificamente pela segurança de tipos entre camadas: o schema é o contrato, e os tipos permanecem do resolver ao cliente.
O backend é organizado em camadas: Resolver → Service → Domain → Prisma. Resolvers permanecem enxutos, services orquestram, lógica de domínio fica isolada do GraphQL e do ORM e Prisma fica restrito à borda de persistência. É mais cerimônia do que um MVP individual estritamente precisa; a escolha é deliberada — a camada de domínio sobrevive a uma troca de transporte ou ORM, e a estrutura se sustenta quando chega um segundo cliente.
Esse segundo cliente explica a decisão de autenticação. O PostgreSQL roda no Supabase, mas a autenticação usa JWT próprio em vez de Supabase Auth: controlar a emissão de tokens mantém o cliente mobile em React Native no roadmap sem acoplar todos os consumidores ao modelo de sessão do Supabase.
apps/web— Next.js App Router, React Server Components e cliente GraphQLapps/api— NestJS + Apollo GraphQL, Prisma ORM e autenticação JWT própria (em andamento)- Banco de dados — PostgreSQL no Supabase
- Ferramentas — monorepo pnpm com pipelines de typecheck, lint e testes
Capturas
Capturas do MVP rodando localmente.
Stack e decisões
| Escolha | Motivo |
|---|---|
| Backend API-first | A API NestJS é a única fonte de verdade; o app web é um consumidor entre clientes futuros |
| GraphQL em vez de REST | Tipagem forte entre camadas — o schema é o contrato do resolver ao cliente |
| Backend em camadas: Resolver → Service → Domain → Prisma | Lógica de domínio isolada de transporte e ORM; cada camada pode evoluir separadamente |
| JWT próprio em vez de Supabase Auth | Controle sobre emissão de tokens para suportar múltiplos clientes no futuro, começando por React Native |
| PostgreSQL no Supabase | Postgres gerenciado, mantendo autenticação e lógica da aplicação na API |
| Monorepo pnpm (apps/web + apps/api) | Tipos e ferramentas compartilhados; pipelines de typecheck, lint e testes para os dois apps |
| Next.js App Router + React Server Components | Busca de dados server-first no cliente web |
Links
- Repositório: github.com/Andersonrrocha/gym-flow