Spring Boot vs Java puro: elige el stack backend correcto
Necesitas construir un servicio backend en Java. ¿Deberías usar Spring Boot o mantenerlo simple con Java puro y el servidor HTTP integrado? Esta elección afecta el tiempo de arranque, el consumo de memoria, la gestión de dependencias y la rapidez con la que puedes entregar. Este artículo desglosa las ventajas y desventajas para que puedas elegir la herramienta adecuada para tu proyecto.
Qué significa "Java puro" para un backend
Java puro aquí significa usar el com.sun.net.httpserver.HttpServer integrado en el JDK o una biblioteca ligera como Javalin o Spark, sin un framework completo. Tú escribes tu propio enrutamiento, análisis de JSON (por ejemplo, con Jackson) y cableado de dependencias. El resultado es una aplicación mínima, de arranque rápido y con pocas dependencias.
Qué aporta Spring Boot
Spring Boot es un framework con opiniones definidas que incluye Spring MVC, Tomcat embebido, autoconfiguración y un vasto ecosistema (Spring Data, Spring Security, Spring Cloud). Gestiona el enrutamiento, la inyección de dependencias, la configuración y características listas para producción como health checks y métricas de forma predeterminada.
Diferencias clave de un vistazo
| Aspecto | Spring Boot | Java puro |
|---|---|---|
| Tiempo de arranque | 1–5 segundos (típico) | Menos de 100 ms |
| Consumo de memoria | 200–500 MB | 20–50 MB |
| Curva de aprendizaje | Pronunciada (muchos conceptos) | Suave (solo Java) |
| Características integradas | Extensas | Mínimas |
| Gestión de dependencias | Los starters simplifican | Manual |
| Mejor para | Aplicaciones complejas y empresariales | Microservicios, CLIs, prototipos |
Cuándo elegir Spring Boot
Spring Boot brilla cuando tu aplicación necesita:
- Desarrollo rápido con autoconfiguración y starters.
- Integración con bases de datos (JPA), seguridad (OAuth2) y mensajería (Kafka).
- Preparación para producción mediante endpoints de Actuator para health, métricas y trazabilidad.
- Colaboración en equipos grandes con convenciones consistentes.
Si estás construyendo una API CRUD típica con autenticación, Spring Boot te ahorrará semanas de código repetitivo.
Cuándo elegir Java puro
Java puro es una mejor opción cuando:
- El tiempo de arranque y la memoria son críticos (por ejemplo, serverless, edge o herramientas CLI).
- Quieres control total sobre cada dependencia y configuración.
- El servicio es pequeño y enfocado, como un receptor de webhooks o un proxy simple.
- Estás aprendiendo los fundamentos del backend y no quieres magia de frameworks.
Comparación de código: una API JSON simple
Veamos cómo cada enfoque maneja un endpoint básico GET /hello que devuelve JSON.
Spring Boot
@RestController
public class HelloController {
@GetMapping("/hello")
public Map<String, String> hello() {
return Map.of("message", "Hello, World!");
}
}
Con Spring Boot, solo anotas y ejecutas. El framework se encarga de la serialización, el enrutamiento y la configuración del servidor.
Java puro (com.sun.net.httpserver)
public class HelloServer {
public static void main(String[] args) throws IOException {
HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
server.createContext("/hello", exchange -> {
String response = "{\"message\":\"Hello, World!\"}";
exchange.getResponseHeaders().set("Content-Type", "application/json");
exchange.sendResponseHeaders(200, response.length());
try (OutputStream os = exchange.getResponseBody()) {
os.write(response.getBytes());
}
});
server.start();
}
}
Java puro requiere la construcción manual de la cadena JSON y el manejo de la respuesta. Para APIs más complejas, tendrías que añadir una biblioteca JSON y un enrutador.
Rendimiento y uso de recursos
El servidor embebido y la autoconfiguración de Spring Boot añaden sobrecarga. Una aplicación mínima de Spring Boot típicamente usa 200–500 MB de heap y arranca en 1–5 segundos. Java puro con el servidor HTTP integrado puede arrancar en menos de 100 ms y usar tan solo 20–50 MB. Si estás desplegando muchas instancias o usando una plataforma serverless, esta diferencia importa.
Ecosistema y herramientas
Spring Boot ofrece un ecosistema rico: Spring Data para bases de datos, Spring Security para autenticación, Spring Cloud para microservicios. También se integra con herramientas de construcción (Maven/Gradle) e IDEs sin problemas. Java puro te deja ensamblar tu propio stack, lo que puede ser liberador pero consume tiempo.
Guía de decisión: ¿cuál deberías elegir?
- Evalúa la complejidad del proyecto. Si necesitas múltiples integraciones (BD, autenticación, mensajería), Spring Boot gana.
- Considera el entorno de despliegue. Para serverless o edge, la baja sobrecarga de Java puro es ventajosa.
- Evalúa la experiencia del equipo. Los equipos familiarizados con Spring serán más productivos con él.
- Prototipa ambos. Construye un endpoint pequeño en cada uno para sentir la diferencia.
Preguntas frecuentes
¿Puedo usar Spring Boot para un microservicio simple?
Sí, pero ten en cuenta la sobrecarga de recursos. Si el servicio es realmente mínimo y necesitas un arranque rápido, Java puro podría ser más eficiente. Spring Boot sigue siendo una opción válida si valoras su ecosistema y no te importa el consumo.
¿Java puro es lo suficientemente rápido para producción?
Absolutamente. El servidor HTTP integrado de Java está listo para producción en muchos casos de uso, especialmente cuando se combina con un proxy inverso como Nginx. Sin embargo, tendrás que implementar características como enrutamiento, manejo de JSON y seguridad por tu cuenta.
¿Cómo migro de Java puro a Spring Boot?
Comienza identificando tus componentes principales: manejadores HTTP, serialización JSON y configuración. Los starters de Spring Boot pueden reemplazar gran parte de tu código manual. Migra de forma incremental, quizás envolviendo tu lógica existente en controladores de Spring.
Reflexiones finales
No hay una respuesta única para todos. Spring Boot acelera el desarrollo de aplicaciones complejas, mientras que Java puro te da control y eficiencia para servicios más simples y sensibles al rendimiento. Evalúa las necesidades de tu proyecto, las habilidades del equipo y los objetivos de despliegue para tomar la decisión correcta.
Cuando estés listo para analizar los logs de tu backend, prueba nuestro Analizador de Logs de Nginx para obtener información sobre el tráfico y los errores.