Manual do Estudante: arquitetura e decisões técnicas de um side project
Fala pessoal, tudo tranquilo?
Queria muito divulgar uma aplicação que estou desenvolvendo, mas vi recentemente um post comentando que o TabNews virou um lugar onde a galera só aparece pra divulgar projeto sem agregar nada, e com certeza é uma crítica válida.
Então resolvi tentar uma abordagem um pouco diferente.
Em vez de só divulgar, vou contar qual problema eu quis resolver, como pensei a solução e algumas decisões técnicas que tomei no caminho (inclusive algumas que talvez não tenham sido as melhores 😅).
A Ideia
A ideia é o seguinte: estou montando o Manual do Estudante, um lugar onde estudantes possam procurar universidades e cursos com base em diferentes critérios e, principalmente, em opiniões de outros estudantes que já estudam lá.
Desenvolvimento
Apesar de usar bastante IA no desenvolvimento, não foi totalmente vibe coding.
Usei IA pra acelerar o trabalho mais repetitivo e “sujo”, mas sempre pensando antes na estrutura das páginas, fluxos e dados. Depois, revisava com bastante atenção tudo o que era gerado. Como é um side project, essa divisão ajudou muito: a IA faz força bruta, eu valido e decido.
Backend e arquitetura
No começo, os dados eram todos mockados. Era basicamente pra entender visual, componentes e UX.
Mas logo pensei: como vou criar interação com estudantes se eles não puderem se cadastrar e deixar reviews? A partir disso, comecei a pensar de verdade no backend e em como essa dinâmica funcionaria.
Uma grande inspiração foi o próprio repositório do TabNews.
Eu nem sabia que dava pra ir tão longe usando o próprio next/server pra montar rotas de backend dentro da mesma aplicação Next.js. Acabei adotando essa ideia e seguindo uma arquitetura serverless, com front e backend vivendo juntos.
Sei que, num projeto “padrão”, separar frontend e backend costuma ser o caminho mais comum, e faz sentido.
Mas, nesse contexto específico, manter tudo na mesma aplicação me ajudou bastante, principalmente porque:
- Facilita manter contexto único da aplicação
- Reduz complexidade inicial (importante pra side project)
- Funciona muito bem com IA, já que todo o domínio está no mesmo código-base
Para o banco, estou usando PostgreSQL com Supabase. Foi a primeira vez que usei o Supabase e realmente foi muito fácil começar.
Auth, banco, permissões… tudo fluiu rápido. O único ponto chato é ter que ficar “acordando” o projeto free quando ele pausa 😅, mas faz parte.
Como ORM, optei pelo Drizzle.
Foi uma escolha mais por curiosidade e vontade de testar algo diferente do que por necessidade. Gostei bastante da proposta mais próxima de SQL e do fato de tudo ser bem tipado, sem aquela sensação de “mágica” demais.
Usei também o Drizzle Kit para gerar e aplicar migrations. Funciona bem, mas achei curioso o fato de ele não suportar migration down. Confesso que estranhei no começo, mas entendi a proposta de tratar migrations como algo imutável e evitar rollback automático.
Sobre autenticação: o Next já oferece uma base bem estruturada, então segui o padrão e fui adaptando conforme a necessidade. Os usuários são salvos no banco e é feito uma verificação se o password está correto na hora do login, bem simples, sem OAuth ou outras ferramentas de autenticação.
Inclusive, sei que sempre tem gente tentando encontrar falhas no TabNews, se alguém quiser dar uma olhada na parte de auth/segurança e me reportar alguma vulnerabilidade, eu agradeço 😂
Eu sei de pelo menos uma… bem básica… talvez nem conte, mas existe.
Curiosidade: esses dias eu acessei o site e estava extremamente lento, algo fora do comum. Minha primeira suspeita foi o Cold Start do Serveless para aplicações Free, até agora não descobri se foi realmente isso. Se mais alguém ja passou por isso, da um toc.
Frontend
No frontend, não usei Lovable nem nenhum template pronto.
Comecei o projeto do zero usando Next.js, Tailwind CSS e Shadcn/ui.
Next.js, SSR e SPA
A escolha do Next.js veio muito pela flexibilidade entre client e server.
Apesar de boa parte da interface funcionar como uma SPA, uso fetch no server e generateMetadata em pontos específicos da aplicação.
Quando o usuário acessa uma universidade específica, a página gera metadata dinâmica no server (title, description, etc.), permitindo que cada universidade tenha sua própria identidade e possa ser indexada corretamente.
A ideia aqui não foi sair fazendo SSR em tudo, mas usar o server onde ele realmente faz diferença. A navegação e interações continuam rápidas no client, enquanto páginas que fazem sentido para indexação e compartilhamento ganham um tratamento mais cuidadoso no server.
Em vários momentos me perguntei se isso realmente importa tanto hoje em dia, já que a descoberta de produtos não depende só de busca orgânica como antes. Mesmo assim, preferi deixar essa base pronta agora, porque o custo é baixo e me dá mais opções no futuro.
Componentes
Optei pelo Tailwind principalmente pela praticidade e velocidade, algo que pra side project faz bastante diferença.
Os componentes do shadcn/ui me agradaram bastante. Acho muito prático ter uma base de componentes já bem pensada em termos de UX e acessibilidade, mas que ao mesmo tempo faz parte do código do projeto. Não é uma biblioteca fechada: dá pra ajustar, refatorar e adaptar conforme a aplicação vai evoluindo.
Primeiros feedbacks e desafios
Um dos primeiros feedbacks que recebi foi bem interessante.
Um amigo tentou usar a plataforma e acabou travando na busca de cursos. O search atual não faz uma busca dinâmica: ele basicamente lista os cursos que já existem na base. Se o curso que a pessoa procura não está ali, ela fica meio “na mão”.
Isso me fez perceber como usuários são imprevisíveis. Algo que, pra mim, fazia sentido do ponto de vista técnico, não necessariamente funciona bem do ponto de vista de quem está usando.
Provavelmente uma das próximas features vai ser melhorar esse search, tornando ele mais “inteligente”: seja com sugestões, resultados aproximados, mensagens mais claras ou até algum tipo de fallback quando o curso não existir ainda.
Esse tipo de feedback cedo dói um pouco 😅, mas ajuda muito a direcionar melhor as próximas decisões do produto.
Se alguém já implementou algo parecido ou tiver sugestões de abordagem, adoraria ouvir.
O maior desafio até agora: dados
A parte mais chata do projeto, disparado, tem sido montar a base de dados.
Tem muita faculdade no Brasil.
Tem mais cursos ainda.
Sem contar graduação, tecnólogo, pós, EAD…
Cheguei a procurar formas de gerar isso automaticamente, mas sempre esbarro na qualidade e credibilidade dos dados. Por enquanto, estou usando listas de universidades mais bem ranqueadas e adicionando manualmente.
A ideia, pelo menos no começo, é deixar isso mais orgânico: se alguém sente falta de uma universidade, eu vou lá e adiciono.
Se alguém tiver sugestões de como gerar esses dados de forma automática sem ser algo totalmente fake, eu adoraria ouvir. Já pensei em web crawler, mas não tenho experiência nisso e, pra um volume grande de páginas, não me parece trivial.
Próximo desafio
O segundo desafio é fazer com que estudantes realmente usem a plataforma e adicionem comentários sobre suas faculdades e cursos.
Talvez isso exija investimento em marketing, talvez dê pra crescer de forma mais orgânica no início, mas ainda estou pensando.
Enfim, tentei dar uma visão mais técnica e de produto da aplicação. Foi tudo bem resumido, mas se alguém tiver dúvidas, sugestões ou críticas, fico super aberto.
Pode ser aqui mesmo, ou pelo email: [email protected] e também pelo siteManual do Estudante.
Valeu, galera!