01
Aplicação pública
- Descoberta de negócios
- Navegação por produtos e serviços
- Favoritos
- Avaliações
- Páginas públicas dos negócios
Produto independente · Retrospectiva de engenharia
Or-by
Construindo uma plataforma de descoberta local da ideia à produção.
O Or-by é uma plataforma de descoberta de negócios locais que levei da ideia à produção. Trabalhei no frontend, backend, banco de dados, infraestrutura e deploy.
- Tipo
- Produto independente
- Papel
- Engenheiro de Software Full Stack
- Início
- dezembro de 2022
- Status
- MVP em produção
Origem
De onde surgiu a ideia
A ideia surgiu ao comparar como as pessoas encontram lojas e serviços em cidades grandes e pequenas. Cidades menores muitas vezes não têm um único lugar para consultar o que os negócios locais oferecem.
Construí o Or-by para ajudar as pessoas a encontrar negócios, produtos e serviços próximos e dar aos proprietários um espaço estruturado para publicar o que oferecem.
Evolução
Do projeto inicial ao MVP em produção
Usei IA para acelerar a implementação. Continuei responsável por produto, arquitetura, revisão, debugging, infraestrutura e decisões de produção.
Comecei a trabalhar no Or-by quando ainda estava aprendendo Node.js, antes de ferramentas de IA generativa fazerem parte do meu fluxo de desenvolvimento.
Mais tarde, adicionei agentes de IA ao meu fluxo de desenvolvimento. Eles me ajudaram a explorar soluções e implementar interfaces com mais rapidez, enquanto eu revisava o resultado e tomava as decisões técnicas.
O uso dessas ferramentas com uma biblioteca de componentes reduziu o tempo entre o design no Figma e a interface implementada e me ajudou a concluir o MVP.
Estrutura do produto
O produto
02
Hub do proprietário
- Cadastro de negócios
- Múltiplos negócios
- Gestão de produtos e serviços
- Gestão de mídia
- Fluxos de assinatura e cobrança
03
Painel administrativo
- Aprovação de negócios
- Moderação
- Gestão da plataforma
04
API REST
- Autenticação
- Autorização
- Regras de negócio
- Persistência
- Integrações
- Webhooks
Mapa do sistema
Arquitetura
A aplicação pública, o hub do proprietário e o admin são aplicações Next.js. As requisições da API chegam ao NGINX na EC2, que as encaminha ao serviço Node.js e Express. A API persiste os dados no RDS PostgreSQL privado por meio do TypeORM, enquanto os uploads usam URLs pré-assinadas para envio direto via PUT ao Cloudflare R2 fora da AWS.
A aplicação pública, o hub do proprietário e o admin são aplicações Next.js. As requisições entram em uma VPC AWS pelo NGINX em uma EC2 pública e chegam ao container Node.js e Express. A API acessa o PostgreSQL em subnets privadas do RDS por meio do TypeORM. Para mídias, a API emite uma URL pré-assinada e o navegador envia diretamente ao Cloudflare R2 fora da AWS. O ECR armazena a imagem da API, e o Terraform provisiona os recursos AWS sem participar do processamento das requisições.
Aplicações Next.jsApp público · Hub do proprietário · Painel administrativo
Interfaces usadas por visitantes, proprietários de negócios e administradores da plataforma.
Fluxo de requisições da API
Fronteira de produção na AWS
Uma VPC com a execução na EC2 em subnet pública e o PostgreSQL em subnets privadas de banco.
Subnet pública · EC2Proxy reverso NGINX
Recebe o tráfego HTTPS e encaminha as requisições da API ao container da aplicação.
Docker Compose · Container da aplicaçãoAPI REST Node.js + Express
Aproximadamente 110 endpoints executados como serviço da aplicação.
Subnets privadasRDS PostgreSQL + TypeORM
Dados persistentes com acesso ao banco restrito ao security group da EC2.
AWS ECR · Registro de imagens dos releases da API.
Fluxo direto de mídia
A API autoriza o upload com uma URL pré-assinada; depois, o navegador envia o arquivo diretamente.
Armazenamento de objetos externoCloudflare R2
Upload direto via PUT a partir da aplicação, fora da fronteira AWS.
Camada de provisionamento · fora do fluxo de requisições
Terraform · Define VPC, subnets, security groups, IAM, EC2, RDS, ECR e alarmes opcionais.
Next.jsReactTypeScriptNode.jsExpressPostgreSQLTypeORMAWSDockerNGINXTerraformCloudflare R2
Notas de engenharia
Aprendizados técnicos
05.1
Arquitetura de uploads
No início do projeto, os uploads de imagem passavam pelo backend. Essa abordagem aumentava o acoplamento e fazia o servidor da aplicação processar transferências de arquivos fora do fluxo principal de negócio.
O fluxo atual usa URLs pré-assinadas: o cliente solicita uma URL autorizada e envia o arquivo diretamente ao Cloudflare R2 via PUT. Tipo, extensão e limite de 5 MB são validados nas fronteiras entre cliente e servidor, mantendo a transferência separada da API.
A próxima iteração deve adicionar estratégias de retry, acompanhamento mais claro do estado do upload e uma recuperação de falhas mais completa.
05.2
Consistência na API
Conforme o backend cresceu para aproximadamente 110 endpoints REST, padrões consistentes para módulos e requisições se tornaram mais importantes.
Uso convenções compartilhadas para validação, services, controllers, erros e persistência, mantendo a API mais fácil de acompanhar à medida que o escopo cresce.
05.3
Segurança da aplicação
O Or-by me deu experiência prática com segurança de aplicações por meio de proteções concretas: schemas Zod para validação de body e query, regras de autenticação e autorização, headers do Helmet, CORS por allowlist, rate limiting direcionado e limites de payload.
Esses controles reduzem riscos comuns, mas não tornam a aplicação absolutamente segura. Trato esse trabalho como parte da arquitetura, e não como algo a adicionar depois do desenvolvimento.
Infraestrutura e produção
Operação do produto em produção
Implantar e operar a aplicação foi a parte mais difícil do projeto.
Meu primeiro deploy na AWS levou cerca de quatro horas apenas para configurar e conectar as partes necessárias. Precisei entender EC2, uma instância privada do RDS PostgreSQL, VPCs, subnets, rede, ECR, containers, domínios e como os componentes da aplicação se comunicariam.
O NGINX foi configurado como proxy reverso, encaminhando as requisições para a aplicação Node.js e evitando a exposição direta do processo da aplicação. O TLS é gerenciado pelo Certbot, e o NGINX aplica o limite configurado de 5 MB para o corpo das requisições. O Docker Compose executa os containers, o Terraform descreve a infraestrutura AWS e o Cloudflare R2 armazena as mídias fora da AWS.
O deploy tornou concreto o trabalho operacional: a aplicação precisa de logs, monitoramento, planos de recuperação, manutenção e uma forma clara de publicar mudanças.
O maior aprendizado
Manter o software vivo
O Or-by me ensinou a avaliar funcionalidades como partes de um sistema em operação, não apenas como código que funciona localmente.
Isso significa considerar falhas, gargalos, acoplamento, recuperação, custos de infraestrutura e disponibilidade nas decisões técnicas.
Hoje considero esse trabalho operacional mais cedo no desenvolvimento.
Próxima iteração
O que eu melhoraria a seguir
- 01Retries, acompanhamento de progresso e recuperação nos uploads diretos
- 02Cobertura mais ampla de testes automatizados
- 03Observabilidade e monitoramento estruturados
- 04Jobs em segundo plano para trabalho assíncrono
- 05Monitoramento do banco e análise de queries
- 06Pipeline de CI/CD e estado remoto do Terraform
Telas reais do produto
Galeria
Continue
Explore o produto ou continue pelo portfólio
Repositório privado