Nota dic/2025: Este era un Rant Técnico (queja personal) con comentarios sobre Spring/Springboot. Un lector me pidió detalles técnicos, aquí va el problema de fondo con Spring Boot y sus tres modos de base de datos.
Me piden con el cliente de los monolitos, implementar algo que segun ellos es Spring, Faces ( javafaces de ibm?) y springboot. Ese proyecto no usa base de datos. Consume un servicio externo, le pone captcha de google y ya. Mi servidor no tiene acceso a Spring. Para saber cual de los tres usar, pregunto como guardan en base de datos y me dicen que jquery.
Les comento que no puedo usar Tomcat en un servidor Rhel ni usar NPM sin root. Dicen que el cliente que salva en backend es jquery(?). Creo que lo que realmente quieren es una solución instalando librerias de java en la maquina que firme. Ok. el problema es que Hay problemas mas serios. La documentación es literalmente una pantalla que dice carpeta1 e index.html, no contenido.
(Como dato Lo resolví con encapsulado a través de php 7.x en servidor RHEL sin root.)
Pero ahora que me piden detalles técnicos sobre Spring Boot, aquí va el problema de fondo que encuentro en el 90% de proyectos que SÍ usan bases de datos…
Un programador actual de Spring o Springboot debe ser de unos 40 mil al mes. Solo que se usaba en 2017/2018 y que ahora se usa Quarkus o javalin, debido a que en su momento springboot era malisimo para aplicaciones complejas. La mayor parte de las cosas complejas son que el framework tiene a su vez modos de usarlo incompatibles entre sí y mal uso de hibernate/JPA.
- Base de datos se puede usar JPA que es lo incluido en springboot pero es mejor usar Spring Data JDBC (NO ES Spring JDBC… se que el nombre es confuso pero son diferentes) en lugar de Spring Data JPA. Asi que de entrada hay tres formas SEMI NATURALES de usar acceso a datos SQL. El mayor problema de Spring Boot no es que tenga tres formas de acceder a datos SQL… es que los equipos usan las tres sin darse cuenta, y nadie sabe cuál están usando realmente.
- Nota para conocedores. No es raro que te pidan un nuevo requisito de sistema que requiere campos adicionales en la base de datos. con JPA/Hibernate puede causar problemas en el ORM…. y desfase de documentación o pruebas unitarias. Ganas un ORM completo pero con sus propios problemas y se usa en empresas medianas o grandes. Mi punto de vista es que da mas problemas que ventajas.
- Usando un ejemplo, Spring JDBC simple es como ADOX/ADO de vb6/.net (bajo nivel y control total), y spring Data JDBC es mucho mas legible tipo DAO (crud simple y consistente)
- En la práctica lo primero que tienes que hacer es revisar cual de los tres están usando y llegar a un estándar. Spring Security es otro tema.
- En resumen:
- Spring JDBC es escribir SQL a mano, como usar JDBC puro. Bajo nivel control total.
- Spring Data JDBC como mapeador simple, tú controlas el SQL pero sin boilerplate, Es consistente y legible.
- Spring Data JPA la magia automática que funciona… hasta que no funciona. Es lo que viene incluido por default.
- Regla. ESTANDARIZAR !!!!
- Spring security cambia tan seguido que de plano a veces no es compatible y no saben que versión están usando, y los paradigmas son completamente diferentes.
Lo bueno es que esta cosa no es complicada. Empezamos a hablar de eso en Noviembre del año pasado, pero ya estamos en la etapa en que mandan el pdf con una foto de la carpeta. La ‘documentación’ que me mandaron: una captura de pantalla de un explorador de archivos. Carpeta1. Index.html. Sin el código fuente. Solo la foto del folder.
Evidentemente no hay ninguna implementación, pero me da la impresión que lo hizo en Spring alguien que por lo que sé salió en 2019 y el nuevo, de 2020 lo que hizo fue pasarse a Spring Boot. Esto es saltar de la sartén para caer al fuego. Eso no se enseña en universidades y aunque se puede medio usar esa tecnología en bancos, el simple manejo de bases de datos es un NO NO en proyectos nuevos. Corregir un proyecto existente Spring mal hecho es mejor empezar de cero.