DEV Community: Ray

Front-end vs Back-end: differences in setting up development environments

Ray — Mon, 25 Aug 2025 16:00:08 +0000

As I transition from Front-end (React + TypeScript) to Back-end (Java + Spring Boot), one of the most striking differences I’ve noticed is the way we set up and work with development environments.

What once seemed simple — running a project locally — took on a whole new dimension when I started working in the Java world.

⚡ Development cycle in Front-end

In the JavaScript/TypeScript ecosystem, the development cycle is fast and dynamic.

You just run:

npm start
# or
yarn start

And the development server is ready to go. The workflow usually involves:

Hot Reload/Fast Refresh: changes in the code are reflected within seconds.

Immediate feedback: results can be seen directly in the browser.

Low initial friction: environment setup is usually simple and straightforward.

➡️ This makes front-end development great for prototyping, rapid iterations, and UI testing.

🏗️ Development cycle in Back-end

In Java + Spring Boot, the cycle has a very different nature. Every change goes through a stricter process:

mvn clean install
# or
gradle build

The compiler checks dependencies, typing, and code integrity.

Automated tests may be triggered.

Only then can you run the application:

mvn spring-boot:run

Feedback isn’t immediate. To validate behavior, I usually rely on:

Swagger/OpenAPI to inspect endpoints

Postman/Insomnia to simulate requests

Application logs to trace issues

➡️ The extra time guarantees safety, consistency, and reliability.

📊 Comparing Front-end vs Back-end

Aspect	Front-end (React/TS)	Back-end (Java/Spring Boot)
Feedback	Instant (hot reload)	Slower (build + run)
Main tools	npm, yarn, Vite, Webpack	Maven, Gradle, IntelliJ
Testing	Unit tests, visual checks	Unit tests, integration, contracts
Local environment	Simple, runs directly	More complex, often with containers
Docker	Mostly for production	Common in development too

📦 Docker in both worlds

Another key difference is the use of Docker.

Front-end: containers are mostly used in staging or production. Local development usually runs directly on the machine.

Back-end: containers show up early in the workflow, simulating databases, queues (Kafka, RabbitMQ), and sometimes even the application itself.

Here’s an example of a docker-compose.yml to run PostgreSQL alongside a Spring Boot project:

version: "3.9"
services:
  db:
    image: postgres:15
    container_name: mydb
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"

With this, the local environment becomes much closer to production, reducing the classic “works on my machine” problem.

🛠️ Practices I’ve been adopting in my transition

During this transition, I’ve realized that a few practices are making a big difference in speeding up my learning and avoiding frustration in my daily routine. These include:

Automating builds and tests — I run tests frequently to make sure small changes don’t break other parts of the system.
Using Docker from the start — I’ve set up containers to simulate databases and other services, which helps me keep my local environment closer to production.
Documenting contracts with Swagger/OpenAPI — I’ve learned how important it is to maintain clear API documentation to simplify integration with other teams.
Learning to read logs carefully — in back-end development, logs have become my main allies for debugging and monitoring application health.
Shifting my mindset — in front-end I was used to instant feedback, but in back-end I’ve learned to see the extra build time as part of ensuring quality and consistency.

These practices are still a work in progress, but I already feel how much they’ve expanded my perspective on software development and brought me closer to my goal of becoming a full-stack developer.

🎯 Conclusion: the journey to Full-stack

This difference between environments has shown me that being Full-stack isn’t just about knowing multiple languages — it’s about being able to adapt to different workflows and rhythms.

Front-end gives you speed and visibility.

Back-end gives you reliability and robustness.

Balancing both worlds is what makes us more complete professionals, ready to deal with complex systems.

💬 Have you ever experienced this contrast between front-end and back-end environments? How was your adaptation?

Front-end vs Back-end: diferenças na configuração de ambientes de desenvolvimento

Ray — Mon, 25 Aug 2025 15:54:07 +0000

Ao longo da minha transição do Front-end (React + TypeScript) para o Back-end (Java + Spring Boot), uma das diferenças mais marcantes que encontrei foi a forma como configuramos e utilizamos os ambientes de desenvolvimento.

O que antes parecia algo simples — rodar o projeto localmente — ganhou uma nova dimensão quando passei a trabalhar no mundo do Java.

⚡ Ciclo de desenvolvimento no Front-end

No ecossistema JavaScript/TypeScript, o ciclo de desenvolvimento é rápido e dinâmico.

Basta rodar:

npm start
# ou
yarn start

E o servidor de desenvolvimento já está disponível. O fluxo normalmente envolve:

Hot Reload/Fast Refresh: mudanças no código são refletidas em segundos.

Feedback imediato: o resultado é visual e pode ser visto direto no navegador.

Pouca fricção inicial: setup de ambiente costuma ser simples e direto.

➡️ Isso facilita prototipagem, iterações rápidas e testes de UI.

🏗️ Ciclo de desenvolvimento no Back-end

No Java + Spring Boot, o ciclo tem outra natureza. Aqui, cada alteração precisa passar por um processo mais rigoroso:

mvn clean install
# ou
gradle build

O compilador verifica dependências, tipagem e integridade.

Testes automatizados podem ser disparados.

Só depois é possível rodar a aplicação:

mvn spring-boot:run

O feedback não é imediato. Para validar o comportamento, geralmente usamos:

Swagger/OpenAPI para inspecionar endpoints

Postman/Insomnia para simular requests

Logs da aplicação para rastrear falhas

➡️ O tempo extra garante segurança, consistência e previsibilidade.

📊 Comparando Front-end vs Back-end

Aspecto	Front-end (React/TS)	Back-end (Java/Spring Boot)
Feedback	Instantâneo (hot reload)	Lento (build + run)
Ferramentas principais	npm, yarn, Vite, Webpack	Maven, Gradle, IntelliJ
Testes	Unitários, integração visual	Unitários, integração, contratos
Ambiente local	Simples, roda direto	Complexo, envolve containers e serviços externos
Docker	Mais comum em produção	Usado também no desenvolvimento

📦 Docker nos dois mundos

Outra diferença marcante está no Docker.

Front-end: geralmente usamos containers só em produção ou homologação. O desenvolvimento local costuma rodar direto na máquina.

Back-end: containers aparecem cedo no fluxo, simulando bancos de dados, filas (Kafka, RabbitMQ) ou até a própria API.

Exemplo de docker-compose.yml para rodar PostgreSQL junto com um projeto Spring Boot:

version: "3.9"
services:
  db:
    image: postgres:15
    container_name: mydb
    environment:
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"

Com isso, o ambiente local fica mais próximo da produção, reduzindo o famoso "funciona na minha máquina".

🛠️ Boas práticas que tenho adotado na transição

Durante essa transição, percebi que algumas práticas têm feito muita diferença para acelerar meu aprendizado e evitar frustrações no dia a dia. São elas:

Automatizar builds e testes — passei a rodar meus testes com frequência para garantir que pequenas mudanças não quebrem outras partes do sistema.
Usar Docker desde o início — configurei containers para simular banco de dados e outros serviços, o que me ajuda a ter um ambiente de desenvolvimento mais próximo do de produção.
Documentar contratos com Swagger/OpenAPI — aprendi a importância de manter APIs bem descritas para facilitar a integração com outros times.
Interpretar logs de forma consciente — no back-end, os logs são meus melhores aliados para entender falhas e acompanhar a saúde da aplicação.
Mudar a mentalidade — no front-end eu estava acostumada com feedback quase instantâneo; no back-end aprendi a valorizar o tempo extra do build como parte do processo de garantir qualidade e consistência.

Essas práticas ainda estão em construção no meu dia a dia, mas já percebo como têm ampliado minha visão sobre desenvolvimento e me aproximado do objetivo de me tornar uma dev full-stack.

🎯 Conclusão: jornada rumo ao Full-stack

Essa diferença entre ambientes me mostrou que ser Full-stack não é apenas dominar linguagens diferentes, mas saber lidar com ritmos de trabalho distintos.

O Front-end te dá velocidade e visualização.

O Back-end te dá confiabilidade e robustez.

Equilibrar esses dois mundos é o que faz de nós profissionais mais completos e preparados para lidar com sistemas complexos.

💬 E você, já passou por esse contraste entre ambientes de front-end e back-end? Como foi sua adaptação?

The importance of documentation and contracts in back-end development across multiple teams

Ray — Tue, 05 Aug 2025 02:47:06 +0000

🇺🇸 English Version:

Today I had a valuable realization while working on back-end development with Java and Spring Boot: the critical role of well-documented APIs and well-defined contracts.

🤝 Multi-team integration demands clarity

In my current environment, it's common to have multiple teams working in parallel, whether developing microservices or micro-frontends, all consuming or exposing the same API endpoints.

That’s why having a clear and updated contract is vital. It ensures everyone involved knows:

What data is expected in requests (input)
What data will be returned (output)
Available HTTP methods (GET, POST, PUT, DELETE)
Possible response statuses (200, 400, 500, etc.)

📜 Example of a JSON contract

When building endpoints, we clearly document their inputs and outputs. Example:

🔽 Request

POST /api/user
{
  "name": "Maria",
  "email": "maria@email.com",
  "age": 25
}

Simple, but this defines a JSON contract that any other team (front-end or back-end) can rely on.

📘 Tools that support API documentation

Swagger/OpenAPI: Generates interactive documentation

Postman: Simulates and shares requests

SpringDoc: Integrates easily with Spring Boot and Swagger

🎯 Best practices for documentation

Keep documentation up-to-date with any contract changes

Use automated tests to validate contracts (e.g., JSON Schema)

Version your APIs to avoid breaking changes

💬 This insight came from a real-world challenge where I had to sync with another front-end team. Documentation played a central role in the success of the delivery.

📌 If you're new to back-end development, remember: documenting is just as important as coding.

A importância da documentação e contratos no back-end em ambientes com múltiplos times

Ray — Tue, 05 Aug 2025 02:34:39 +0000

Hoje tive um insight valioso enquanto trabalhava com back-end usando Java e Spring Boot, e quero compartilhar com vocês algo que pode parecer simples, mas faz toda a diferença: a importância de uma boa documentação de API e contratos bem definidos.

🤝 Integração entre times exige contratos claros

No cenário atual em que trabalho, é comum termos vários times atuando em paralelo, seja no desenvolvimento de microserviços ou micro-frontends, todos consumindo (ou provendo) os mesmos pontos de API.

Nesse contexto, contratos bem documentados são mais do que úteis — são indispensáveis. Eles garantem que todas as partes envolvidas saibam exatamente:

Quais dados esperar na requisição (input)
Quais dados a API vai retornar (output)
Quais são os métodos disponíveis (GET, POST, PUT, DELETE)
Quais são os possíveis status de resposta (200, 400, 500 etc.)

📜 Exemplo de contrato: entrada e saída JSON

Ao criar endpoints no back-end, documentamos suas especificações de forma clara. Exemplo:

🔽 Request

POST /api/usuario
{
  "nome": "Maria",
  "email": "maria@email.com",
  "idade": 25
}

Esse exemplo é simples, mas já estabelece um contrato JSON que pode ser usado por qualquer time, incluindo o front-end.

📘 Ferramentas que ajudam na documentação

Swagger/OpenAPI: Gera documentação interativa dos endpoints
Postman: Simula requisições e compartilha coleções
SpringDoc: Integra facilmente com Spring Boot e Swagger

🎯 Boas práticas na documentação

Atualizar a documentação sempre que um contrato mudar

Validar os contratos com testes automatizados (como com JSON Schema)

Versionar APIs para evitar breaking changes para quem consome

💬 Esse aprendizado surgiu de um momento prático, onde precisei alinhar meu serviço com um front-end de outro time. A documentação foi o ponto central para o sucesso dessa entrega.

📌 Se você está começando no back-end agora, lembre-se: documentar é tão importante quanto codar.

From React to Java: My Journey from Front-end to Back-end on the Road to Full Stack Development - English Version

Ray — Mon, 04 Aug 2025 13:56:53 +0000

After two years working mainly with front-end development using React, Typescript, and other modern tools from the JavaScript ecosystem, I recently started a transition to the back-end world — specifically using Java and Spring Framework.

In this post, I’ll share the main technical challenges I’ve faced, the tools I'm using, and how I'm balancing all of this with my Software Engineering degree and personal projects.

🌐 From Components to Endpoints: The Mindset Shift

On the front-end, my daily tasks involved UI/UX, state management, and API integration. Now, in back-end development, the challenges are quite different:

Business logic
Data management (SQL/NoSQL)
Building RESTful APIs with Spring Boot
Authentication and Authorization
Monitoring, logs, and performance
Clean architecture and best practices like SOLID, DDD

This transition demands a more analytical and systemic mindset — which is both challenging and rewarding.

⚙️ Tools & Technologies I'm Using

Area	Tools/Technologies
Language	Java 17
Framework	Spring Boot, Spring Security, Spring Data
IDE	IntelliJ IDEA
Database	PostgreSQL, MongoDB
Testing	JUnit 5, Mockito
APIs	Swagger, Postman
Others	Docker, Git, GitLab CI/CD

🔍 Technical Challenges I Faced

New Language: Java is more verbose and requires more attention to structure and types.
New IDE: Switching from VSCode to IntelliJ took some time to get used to.
Higher Complexity: Architecture and design patterns are key in back-end development.
Microservices: Understanding service communication, isolation, and resilience has been a big leap.

🎯 Expectations and Career Goals

This shift isn’t just technical — it's also strategic. I want to become a high-level full stack software engineer, and for that I need to understand:

Application security
Performance and scalability
System health monitoring
Decision-making in distributed architectures

🕒 Balancing Work, University, and Projects

Studying Software Engineering helps me a lot with theory. But combining college, work, and self-study requires time management, patience, and resilience.

One strategy is to always keep personal projects going — building APIs, experimenting with microservices, and applying concepts in real scenarios.

💡 Advice for Others Making This Transition

Start small: Build basic APIs and expand gradually.
Learn the fundamentals: HTTP, databases, architecture principles.
Test everything: Robust testing is essential in back-end development.
Don’t give up: The learning curve is steep, but your system-level understanding will grow immensely.

🚀 In the next posts I’ll share practical code examples using Spring Boot and testing with JUnit/Mockito. Follow me here on Dev.to to stay tuned!

De React a Java: Minha jornada de transição do Front-end para o Back-end com foco em Full Stack

Ray — Mon, 04 Aug 2025 13:54:53 +0000

Depois de dois anos atuando com foco em desenvolvimento front-end utilizando React, Typescript e ferramentas modernas do ecossistema JavaScript, iniciei recentemente uma transição para o universo back-end, mais especificamente utilizando Java com Spring Framework.

Neste post, compartilho as principais mudanças técnicas que enfrentei, os aprendizados e as ferramentas que estou usando nessa nova fase — tudo isso conciliando com a graduação em Engenharia de Software e os projetos pessoais que estou desenvolvendo.

🌐 De Componentes a Endpoints: a virada de chave

No front-end, minha rotina era centrada em UI/UX, manipulação de estados e integração com APIs. Agora, no back-end, meus desafios passaram a incluir:

Lógica de negócios complexa
Gerenciamento de dados com bancos relacionais e não relacionais
Criação de APIs RESTful com Spring Boot
Validação, autenticação e autorização
Observabilidade, logs e performance
Padronização com boas práticas como SOLID, Clean Architecture, DDD

A mudança exige uma mentalidade mais sistêmica e analítica — e isso não é simples. Mas é exatamente o que me motiva.

⚙️ Ferramentas e Tecnologias em Uso

Área	Ferramenta/Tecnologia
Linguagem	Java 17
Framework	Spring Boot, Spring Security, Spring Data
IDE	IntelliJ IDEA (com plugin para Spring)
Banco de dados	PostgreSQL, MongoDB
Testes	JUnit 5, Mockito
APIs	Swagger, Postman
Outros	Docker, Git, GitLab CI/CD

🔍 Dificuldades Técnicas Enfrentadas

Nova linguagem: O paradigma mais verboso e fortemente tipado do Java exige mais atenção aos detalhes.
IDE nova: Migrar do VSCode para o IntelliJ foi desafiador, especialmente no início.
Complexidade: O nível de abstração e as decisões técnicas no back-end exigem mais conhecimento de arquitetura.
Microserviços: Entender como os serviços se comunicam, escalam e se isolam foi (e ainda é) um aprendizado constante.

🎯 Expectativas e Metas

A transição não é apenas técnica, mas também estratégica. Meu objetivo é me tornar uma engenheira de software full stack de alto nível. Para isso, quero entender e dominar:

Segurança e autenticação
Armazenamento e performance
Monitoramento e resiliência de aplicações
Design de sistemas complexos

🕒 Conciliando com a Faculdade e Projetos Pessoais

Estudar Engenharia de Software me dá um suporte teórico incrível. No entanto, conciliar as aulas, o trabalho e o estudo autônomo exige gestão de tempo, paciência e resiliência.

Uma das estratégias que uso é manter projetos pessoais que aplicam o que aprendo, como APIs REST com autenticação JWT e microserviços simulando sistemas reais.

💡 Dica pra quem está nesse caminho

Comece pequeno: pratique a criação de APIs simples e depois vá escalando.
Aprenda os fundamentos: entenda HTTP, banco de dados, arquitetura.
Teste tudo: o back-end exige testes robustos e controle de exceções.
Não desanime: a curva de aprendizado é real, mas o ganho de visão sistêmica é enorme.

🚀 Em breve vou compartilhar exemplos práticos de código usando Spring Boot e testes com JUnit/Mockito. Me segue aqui no Dev.to para acompanhar!