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 criada para ajudar pessoas a descobrir negócios, produtos e serviços próximos. Ele se tornou meu principal projeto independente e o lugar onde aprendi que construir software envolve muito mais do que escrever código.
- 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 de uma observação simples. Grandes cidades normalmente possuem shopping centers que reúnem lojas, produtos e serviços em um único lugar. Cidades menores muitas vezes não possuem essa mesma experiência.
Comecei a pensar se um produto digital poderia funcionar como uma espécie de shopping virtual local, ajudando as pessoas a descobrir o que existe ao seu redor e dando aos negócios locais uma forma mais estruturada de apresentar seus produtos e serviços.
Evolução
De um projeto antigo a um MVP real
A IA acelerou a implementação. Produto, arquitetura, revisão, debugging, infraestrutura e decisões de produção continuaram sob minha responsabilidade.
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.
O projeto evoluiu ao longo do tempo. Mais tarde, passei a usar agentes de IA como assistentes de desenvolvimento. Eles não substituíram arquitetura, validação, debugging ou decisões técnicas, mas reduziram o tempo necessário para explorar soluções e construir interfaces.
O desenvolvimento do frontend costumava ser uma das partes mais lentas do meu processo, pois eu primeiro desenhava as telas em ferramentas como o Figma e depois as implementava manualmente. A combinação de desenvolvimento assistido por IA com uma biblioteca de componentes acelerou significativamente a criação das interfaces e ajudou a transformar a ideia em um 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
Crescimento sustentável
Conforme o backend cresceu para aproximadamente 110 endpoints REST, padrões consistentes e uma arquitetura clara se tornaram cada vez mais importantes.
Seguir as mesmas convenções para módulos, validação, services, controllers, erros e persistência tornou a API mais fácil de compreender e manter, mesmo com o aumento do escopo.
05.3
Segurança como arquitetura
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 mecanismos reduzem riscos comuns sem sugerir segurança absoluta. A mudança importante foi tratar o fortalecimento da segurança como parte da arquitetura, e não como uma tarefa deixada para depois do desenvolvimento.
Infraestrutura e produção
A parte mais difícil não foi o código
A parte mais desafiadora do Or-by foi tornar a aplicação disponível em um ambiente real de produção.
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.
Essa experiência mudou a forma como penso sobre engenharia de software. Escrever funcionalidades é apenas uma parte do trabalho. Uma aplicação real também precisa ser implantada, observada, mantida, recuperada e mantida disponível.
O maior aprendizado
Manter o software vivo
Meu maior aprendizado com o Or-by não foi sobre um framework ou uma linguagem.
O projeto me mostrou que engenharia de software real não é apenas fazer uma funcionalidade funcionar. Também envolve antecipar falhas, compreender gargalos, reduzir acoplamento, planejar recuperação, controlar custos de infraestrutura e manter a aplicação disponível ao longo do tempo.
É nesse ponto que o software deixa de ser apenas código e se torna um sistema que alguém precisa operar e assumir responsabilidade.
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