Por que ter um padrão
Existem dezenas de jeitos de construir um sistema — dezenas de linguagens, frameworks e bancos de dados, cada um com seus fãs. Justamente por isso a Highpar define um conjunto de tecnologias padrão: a ideia não é podar a criatividade de quem desenvolve, é fazer com que todo projeto da casa fale a mesma língua. Um sistema novo escolhe a mesma base que os anteriores, em vez de cada um seguir por um caminho próprio.
Isso compensa por motivos bem práticos:
- Manutenção no futuro. Sistema bom é sistema que vai durar — e quem mexer nele daqui a dois anos pode não ser quem o escreveu. Se a base é a mesma de sempre, qualquer pessoa do time entra no projeto e se vira.
- Entrada e troca de pessoas. Quando todo projeto usa a mesma stack, aprender uma vez serve para todos. Um novo integrante fica produtivo mais rápido, e ninguém vira "o único que entende aquele sistema esquisito".
- Suporte da TI. A TI consegue dar suporte, montar backup, monitorar e manter a infraestrutura quando ela é a mesma em todo lugar — e não uma coleção de tecnologias avulsas, cada uma exigindo um cuidado diferente.
- Reaproveitamento. Configurações, componentes e soluções de um projeto servem para o próximo. Não se reinventa a roda a cada sistema novo.
- Menos superfície de risco. Quanto menos tecnologias diferentes em uso, menos coisas para manter atualizadas e protegidas. Padronizar também é segurança.
A IA está escrevendo cada vez mais código — é o que vem nos passos de assistentes de código e de agentes. Um padrão claro é o que mantém o que a IA gera revisável e consistente: ela segue a base da casa, e você consegue conferir o resultado em vez de receber cada projeto num dialeto diferente.
Aplicações web: Next.js
O que é: o Next.js é um framework para construir aplicações web — telas, páginas e a lógica por trás delas. Ele é baseado no React (a biblioteca de interface mais usada do mercado) e reúne, num só projeto, a parte que aparece no navegador e a parte de servidor que conversa com o banco de dados.
O padrão: aplicações web novas na Highpar são feitas em Next.js. Não em Angular, Vue, Svelte ou um back-end montado peça por peça — e nem em React "puro" sem a estrutura que o Next já entrega pronta.
Por que ele e não outro:
- Tem um ecossistema grande e maduro: muita documentação, muita gente usando, fácil encontrar resposta para um problema.
- Junta front-end e back-end num único projeto, o que simplifica a estrutura e reduz o número de peças para manter.
- Já é o que a Highpar usa nos projetos atuais — então tudo que aprendemos e construímos num serve para o próximo.
- Por ser tão difundido, as IAs conhecem bem: assistentes de código geram código Next de boa qualidade, o que torna o trabalho com IA mais previsível.
Começar um projeto novo em outro framework só por preferência pessoal, deixando-o diferente de todo o resto da casa.
Next.js, como nos demais projetos. Se houver um motivo técnico forte para fugir do padrão, combine antes (ver Seção 6).
Banco de dados: PostgreSQL
O que é: o PostgreSQL (ou só "Postgres") é um banco de dados relacional — o lugar organizado, em tabelas, onde a informação do sistema fica guardada. "Relacional" e "SQL" são a forma mais comum e consolidada de estruturar dados; o Postgres é uma das implementações mais sólidas que existem.
O padrão: quando um projeto precisa de banco de dados relacional, ele usa PostgreSQL — não MySQL, SQL Server, Oracle ou SQLite.
Por que ele e não outro:
- É robusto e gratuito (open-source): sem custo de licença e com fama de confiável mesmo com muito dado e muito acesso.
- É completo: dá conta tanto do feijão com arroz quanto de necessidades mais avançadas, sem precisar trocar de banco no meio do caminho.
- A TI já o mantém no padrão da casa — com backup, monitoramento e suporte montados em cima dele. Um banco avulso, num serviço que só uma pessoa conhece, fica fora desse cuidado.
Como já vale para qualquer dado da empresa: o banco é criado no padrão da casa, com a TI — e não num serviço gratuito aberto por conta própria. Assim ele entra no backup e fica sob controle, em vez de virar uma "ilha" que ninguém mais enxerga.
O resto do padrão
O padrão não para no framework e no banco. Algumas outras escolhas mantêm os projetos parecidos por dentro — e valem como ponto de partida (a TI confirma o que está em vigor):
| Camada | Padrão | Por quê |
|---|---|---|
| Linguagem | TypeScript, não JavaScript puro | A tipagem avisa de muitos erros ainda na escrita, antes de virar bug em produção. |
| Acesso ao banco | Um ORM padrão (ex.: Prisma) | Conversar com o Postgres sempre do mesmo jeito, com segurança e menos código repetido. |
| Pacotes | Um gerenciador único (ex.: npm ou pnpm) | Todo mundo instalando dependências da mesma forma evita conflito e confusão. |
| Estilo de código | Linter + formatador (ex.: ESLint e Prettier) | O código sai com a mesma cara, não importa quem — ou qual IA — escreveu. |
Os nomes entre parênteses são sugestões para esta primeira versão; o que importa é a regra de fundo: uma escolha por camada, a mesma em todos os projetos.
O template pronto: faça um fork e comece
A boa notícia é que você não precisa montar nada disso à mão. A Highpar mantém um template de projeto Next.js — um repositório-modelo no GitHub da organização com a base inteira já configurada: Next.js com TypeScript, a conexão com o PostgreSQL pelo ORM, o linter e o formatador ligados, a estrutura de pastas organizada e o esquema de variáveis de ambiente pronto para receber os segredos.
Para começar um projeto novo, parta dele: faça um fork (ou use o botão "Use this template" do GitHub) e já comece a trabalhar em cima de uma base que segue o padrão — sem perder o primeiro dia resolvendo configuração, versão de pacote e ajuste de ferramenta. A dor de cabeça de preparar o terreno já foi resolvida uma vez, para todo mundo.
Além de poupar a configuração inicial, ele garante que todo projeto nasce igual aos outros — exatamente o padrão das seções anteriores, sem cada um reinventar do zero. E quando a base do template melhora, a melhoria já vem de brinde nos próximos projetos.
Segredos e configuração
Todo sistema tem informações sensíveis para funcionar: senha do banco, chave de algum serviço, token de acesso. A regra é direta: nada disso fica escrito dentro do código.
O código vai para o GitHub e carrega histórico — uma senha colada nele pode ficar registrada para sempre, mesmo depois de "apagada". Em vez disso, segredos ficam em variáveis de ambiente (configuração que mora fora do código) e guardados no cofre de senhas da empresa, sob cuidado da TI.
"Deixo a chave no código só pra testar e tiro depois" é como sai a maioria dos vazamentos. Uma vez no histórico do repositório, ela já foi. E vale o mesmo cuidado das IAs de chat: nunca cole um segredo num assistente de IA para ele "dar uma olhada".
Fora do padrão? Combine antes
Vai aparecer o caso em que outra tecnologia parece a escolha certa — um framework diferente, outro banco, uma biblioteca fora da lista. Quando isso acontecer, converse antes com a TI ou com o responsável técnico, em vez de simplesmente seguir por fora.
Não é para travar: é o mesmo reflexo do "shadow IT" que aparece nas Ferramentas. Sair do padrão por conta própria cria um sistema que só uma pessoa sabe manter, que a TI não consegue suportar e que ninguém mais consegue evoluir. O padrão pode mudar — e deve, quando há um bom motivo — mas de forma combinada, virando o novo padrão de todo mundo, e não uma exceção solta.
Na dúvida entre "uso o que eu prefiro agora" e "alinho com a TI", alinhe. Ou o padrão atual resolve o seu caso, ou o seu caso é bom o bastante para mudar o padrão — e aí ele muda para todos.
Antes de começar
Uma conferência rápida ao iniciar um projeto novo:
- Comecei a partir do template Next.js da Highpar (fork), em vez de configurar do zero.
- Aplicação web em Next.js, com TypeScript.
- Dados em PostgreSQL, criado no padrão da casa com a TI.
- Código no GitHub da organização, não numa conta pessoal.
- Nenhum segredo escrito no código — tudo em variáveis de ambiente e no cofre.
- Linter e formatador configurados desde o começo.
- Preciso fugir do padrão? Combinei antes com a TI.
Seguindo esses pontos, cada sistema novo nasce parecido com os outros — mais fácil de manter, de passar adiante e de manter seguro no longo prazo.