Da UI ao Servidor: Minha jornada de React para Node.js

A velocidade com que a IAentrou no nosso dia a dia como dev me trouxe alguns medos. Um deles foi a sensação de que o desenvolvimento frontend poderia estar perto do fim ou, pelo menos, de uma grande transformação. Com isso em mente pensei: por que não aprender mais sobre backend?
A barreira de entrada para Node.js é baixa: mesma linguagem, mesmo paradigma, ecossistema familiar. Foi assim que essa jornada começou.

A ideia aqui é contar um pouco da minha história e de como decidi me aprofundar em uma nova área por escolha pessoal. Se você está em um momento mais iniciante, talvez consiga aprender com o pouco que vou compartilhar aqui. Espero que sim :)

Quem sou eu?

Comecei na área em 2021, como estagiário frontend, e segui nesse caminho pelos quatro anos seguintes até mudar de empresa em busca de novos desafios. Hoje continuo trabalhando principalmente com frontend, com React e Next.js.

Tenho medo do novo, mas eu gosto de pensar na possibilidade de ser desafiado e poder construir coisas diferentes. Com essa mentalidade + o assunto do momento , AIs, fez com que eu desse de cara para mais um novo desafio → mergulhar para o backend com Node.js

Sair da zona de conforto

Quando falamos de sair da zona de conforto no mundo da programação, e ainda mais com o avanço de novas tecnologias, acaba trazendo muitos benefícios de entender o escopo/ambiente de que você desenvolve.
É muito valioso entender o que o seu par de backend está fazendo, por que certas decisões técnicas estão sendo tomadas e, principalmente, conseguir opinar com confiança. Alguns benefícios de entender o outro lado:

• melhor comunicação com o time de backend
• mais autonomia para criação de features end-to-end
• visão mais completa como o todo

No meu caso que foi com Node.js a linguagem de programação não foi uma barreira. Inclusive, ela é até um incentivo para que você aprenda. A base, a sintaxe, operadores e semântica praticamente idênticas. O que muda então? Arquitetura, o funcionamento de cada “peça” do mecanismo, performance em consultas ao banco de dados, responsabilidade de cada camada e por aí vai.

O que já sabia vs o que precisa aprender?

Como comentei anteriormente, a linguagem foi um ponto positivo. Além disso, algumas bibliotecas já faziam parte da minha rotina, como o uso do zod para validação de schemas. Também já estava acostumado com código assíncrono, async/await e Promises, o que ajudou bastante a não “apanhar” tanto nos fluxos de I/O.
Onde eu realmente precisei estudar mais a fundo foi em:

Precisei estudar mais afundo sobre as camadas de C*lean Architeture,* aplicar bem o DDD (Domain Drive Design), consultas SQL → integradas com ORM, docker e containerização e logs → que aparenta ser “bobo” mas é muito importante para encontrar bugs/métricas de sistemas

• Camadas da Clean Architecture e como aplicar na prática
• DDD (Domain-Driven Design) no dia a dia
• Consultas SQL integradas com ORM
• Docker e containerização
• Logs bem pensados, que são fundamentais para encontrar bugs e medir o comportamento do sistema

No início das tasks de backend, usando o Cursor do meu lado, eu tomei um cuidado consciente: não usar a IA só para cuspir o resultado final. Eu trazia o contexto do que estava aprendendo e pedia orientação: onde mexer, por que mexer, passo a passo, boas práticas e alternativas. Confesso que foi com isso que fui modelando e entendendo um pouco mais sobre o funcionamento do backend e não apenas pegar a solução pronta da AI.

Como trabalhar com backend me ajudou a ser melhor no front?

No passar das semanas vendo curso de Node.js e já desenvolvendo tarefas de baixa e média complexidade no backend, fui trazendo uma bagagem de melhor organização arquitetural e quando eu desenvolvia alguma tarefa no front eu usava essas referências que tinha no backend.

No React já temos uma "filosofia" de separar bem a responsabilidade de componentes da árvore, mas acredito que eu pecava em alguns cenários onde tinha muita lógica com UI → separação de responsabilidades dentro dos arquivos/contextos.

Antes: tudo misturado no componente

// ❌ Componente fazendo tudo
function UserProfile() {
  const { data: user, isLoading } = useQuery({
    queryKey: ['user'],
    queryFn: async () => {
      const res = await fetch('/api/user')
      const data = await res.json()
      return {
        ...data,
        fullName: `${data.firstName} ${data.lastName}`,
        createdAt: new Date(data.createdAt).toLocaleDateString('pt-BR')
      }
    }
  })

  if (isLoading) return <Loading />
  return <div>Nome: {user.fullName}</div>
}

Depois: separando como aprendi no backend (services, repositories, formatters)

// services/user.ts - lógica de negócio isolada
export async function getUser(): Promise<User> {
  const response = await api.get('/user')
  return formatUser(response.data)
}

// utils/formatters.ts - transformações reutilizáveis
export function formatUser(data: UserDTO): User {
  return {
    ...data,
    fullName: `${data.firstName} ${data.lastName}`,
    createdAt: new Date(data.createdAt).toLocaleDateString('pt-BR')
  }
}

// hooks/useUser.ts - estado e side-effects
export function useUser() {
  return useQuery({ queryKey: ['user'], queryFn: getUser })
}

// ✅ Componente limpo, só UI
function UserProfile() {
  const { data: user, isLoading } = useUser()
  if (isLoading) return <Spinner />
  return <div>{user.fullName}</div>
}

Além de deixar o componente mais limpo, isso facilitou muito o debugging geral. Quando algo dava problema em produção ou o QA encontrava um bug, eu já conseguia raciocinar melhor:

• É algo no cliente ou no servidor?
• Algum serviço externo falhou?
• Preciso olhar os logs no Datadog ou a DQL da Rabbit?

Ter noção de como o backend funciona reduziu bastante o tempo que eu gasto “caçando” o problema e me trouxe propriedade pois eu já sabia o contexto de client e server.

Conectando mundos

Frontend não é apenas “pintar” cor de botão e Backend não é apenas devolver um json. Os dois se completam para fazer um sistema que entregue valor ao usuário final. Quando todo o time técnico entende o contexto dos requisitos e o contexto técnico de como funcionam as coisas é um ganho enorme com isso.

Está valendo muito a pena mergulhar no backend e entender como tudo isso funciona. Os benefícios vão além de “dominar mais uma área”, é uma forma de se remodelar como profissional, se capacitar e enxergar problemas com outra lente.

Com o avanço da inteligência artificial, acredito que profissionais com visão mais completa e generalista vão ter ainda mais espaço.
É aí que esse tipo de jornada → sair da UI e encostar no servidor, começa a fazer muito sentido.

Você já pensou em fazer essa jornada? Sair da UI e ir para o lado do Server ou vice-versa?