Dropwizard vs. Spring Boot

¿Cómo obtener una aplicación Java corporativa, desde cero, en el tiempo más corto posible?

Yo no soy una persona madrugadora, así que a veces me toma un tiempo tener “todos los sistemas listos para el despegue”. Este mismo también solía ser el caso con las aplicaciones Java hasta no hace mucho, pero a diferencia de la invención de la función de posponer la alarma que le inventaron a los despertadores, la solución de la que vamos a hablar aquí tiene mucho sentido. Con los frameworks modernos de código abierto, tales como Dropwizard, Spring Boot, Grails (de Groovy) y Play! (de Scala), puedes crear una aplicación desde cero y dejarla lista para producción en cuestión de minutos. Aunque no seas una persona madrugadora. Y aunque no adores los sombreros de mago (“wizard”). En este artículo, analizaremos las similitudes y diferencias entre los frameworks livianos basados en Java: Dropwizard y Spring Boot.

La compensación: libertad de elección vs. requerimiento de velocidad

No importa por cuál framework te inclines, vas a sacrificar algo de libertad de elección, pues tanto Dropwizard como Spring Boot son altamente obstinados y creen firmemente en la convención por sobre la configuración. ¿Cuán firmemente? Eso es lo que vas a averiguar en una comparación frente a frente que realizamos, examinando los diferentes sabores de librerías de terceros que cada uno agrega a la receta. La mayoría de las funcionalidades esenciales (si acaso no todas ellas) que una aplicación a nivel de producción requiere, ya vienen incluidas o bien están disponibles como posibles integraciones.

La ventaja de este sacrificio reside en la rapidez. Aunque a veces sea divertido perder un poco el tiempo probando nuevas librerías y personalizando hasta la perfección tu propio entorno, cuando necesitas hacer andar algo rápidamente, es mejor delegar esas decisiones y librarte de la complejidad que ellas acarrean. No es precisamente un escenario como el de la píldora azul o la píldora roja: mucho más adelante, cuando ya esté funcionando, lo más probable es que vas a poder personalizarla y retocarla a gusto, si fuera necesario. Nada más apunta tu herramienta de desarrollo favorita, ya sea Gradle o Maven, hacia Dropwizard y Spring Boot y estás listo para zarpar.

Indaguemos y averigüemos qué aspectos de cada framework te dejarán más encerrado y en cuáles puedes ser más flexible.

Aviso aguafiestas: ya nos encontramos con un problema similar en Takipi y decidimos probar Dropwizard para una versión on-premise de Takipi para empresas. Pero lo que una vez supo verse como la opción por defecto (y la única), con Dropwizard, nos llevó a romper con algunos prejuicios que teníamos con Spring Boot y las agotadoras configuraciones XML.

Dropwizard vs. Spring Boot: ¿Quién se hace cargo de tu backend?

Una aplicación corporativa depende de muchos componentes y cada framework ya ha hecho las elecciones por nosotros. Todas las armas elegidas para obtener una aplicación web RESTful desde cero aparecen aquí, especificadas en la tabla de más abajo, con Dropwizard en la esquina izquierda, con un sombrero de “wizard” (mago), y Spring Boot en la esquina derecha, con los pantalones cortos de color verde. Las librerías esenciales incorporadas y las extensiones están separadas por colores, con las dependencias internas de Spring señaladas en blanco.

Dropwizard vs. Spring boot: librerías de terceros

Ok, ahora que ya tenemos una mejor perspectiva, veamos qué nos dice todo esto. También recomiendo dar una mirada más detallada a cada uno de los frameworks, ya que todo en ellos es de código abierto y está disponible para que puedas deleitar tu vista en GitHub: aquí están los archivos fuente de Dropwizard, y aquí los de Spring Boot.

Dependencias de Spring

Tal como dice en el envase, Spring Boot se centra en aplicaciones Spring. Así que si deseas ingresar en el ecosistema Spring o si ya te es familiar y quieres preparar una aplicación rápidamente, probablemente el camino sería por aquí. El soporte REST, y las funcionalidades DevOps de las que hablaremos más adelante, tales como mediciones y análisis de salud, están basadas en la esencia del Spring Framework, mientras que DropWizard pone su soporte REST con Jersey. Ese es prácticamente el único aspecto en que Spring Boot te deja encerrado, aunque es más flexible en otros frentes (EDITADO: Spring agregó soporte para JAX-RS en la v1.2, y también puede ser utilizado con Jersey.)

Servidor HTTP

Aquí podemos ver cómo Spring Boot puede resultar más flexible. Dropwizard toma el camino de la convención por sobre la configuración de una manera un poco más acentuada que Spring Boot, y está completamente basado en Jetty, mientras que Spring Boot toma la versión incrustable de Tomcat por defecto, pero deja una salida, por si acaso prefieres Jetty o aún Undertow, de RedHat.

Logs

Este es otro ejemplo del mismo asunto de la convención por sobre la configuración. Dropwizard se cambió de log4j a Logback en la v0.4. De lado de Spring Boot, tenemos que elegir entre Logback, log4j y log4j2 si necesitamos hacer logs. A propósito, si estás usando Logback, puedes dar una ojeada a esta evaluación que hicimos, comparando el rendimiento de diferentes métodos para realizar logs.

Inyección de dependencias

Una diferencia preponderante entre ambos frameworks es el soporte para la inyección de dependencias. Como algunos ya saben, el paquete esencial de Spring ya viene con su soporte para inyección de dependencias incorporado, mientras que en el caso de Dropwizard dicha funcionalidad no viene incluida, por lo que tendrás que elegir una integración de la comunidad que la soporte. Una alternativa muy popular es Guice, de Google, y usar una de las integraciones dirigidas por la comunidad.

Pruebas: Fest vs. Hamcrest

Ambos frameworks cuentan con un módulo específicamente dedicado a las pruebas, dropwizard-testing y spring-boot-starter-test, incluyendo las dependencias JUnit y Mockito. Spring Boot, naturalmente, también usa Spring Test, y la diferencia principal está en los objetos matcher, que verifican si distintos objetos siguen el mismo patrón. Dropwizard prefiere los matchers FEST (que ya no son desarrollados) (EDITADO: en la reciente versión 0.8, se cambió para AssertJ) y Spring Boot se inclina por Hamcrest.

Depuración en producción

A diferencia de lo que ocurre con las soluciones enfocadas en pruebas durante la etapa de desarrollo, cuando tu aplicación es implementada en producción no hay ninguna garantía de que todo vaya a salir tal como fue planeado. Con Takipi incluido en la receta, puedes saber cuáles errores representan el riesgo más alto, priorizarlos y recibir información procesable sobre cómo resolverlos. Si quieres mejorar tu entorno, definitivamente deberías probarlo, para ver cuándo y por qué el código falla en producción.

No hay Dev sin Ops

Para ganarse el calificativo de aplicación corporativa, cada framework ofrece -entre sus funcionalidades nativas- soporte para mediciones, tareas y análisis de salud. En pocas palabras, las mediciones te permiten mantenerte al tanto de estadísticas tales como el uso de memoria y el tiempo que demoran ciertas áreas de tu código en ejecutarse. Los análisis de salud son una forma de probar sobre la marcha y responder preguntas como “¿Este socket sigue abierto?” o “¿La conexión con la base de datos todavía está viva?”. Y con soporte para tareas, puedes programar operaciones de mantenimiento o tareas periódicas.

La librería de mediciones de Dropwizard (Metrics) se ha hecho de bastante popularidad, así que puedes añadirla a cualquier proyecto, o hasta usarla con las mediciones de Spring Boot, para obtener información sobre lo que tu código hace en producción. Una funcionalidad sumamente interesante es la de informar a otros servicios tales como Graphite o Ganglia, y más de 20 integraciones disponibles. Los análisis de salud también vienen con las mediciones de Dropwizard, y las tareas son implementadas como parte del framework. Por su parte, en Spring Boot, el framework usa las funcionalidades nativas de Spring para soportar su lado Ops.

Una nota sobre el vuelco hacia el desuso de los contenedores

El eje principal que permitió la creación de Dropwizard, seguido por Spring Boot unos pocos años más tarde, es el de los servidores HTTP Java sin contenedores. A diferencia de un contenedor independiente, puedes agregar un servidor HTTP como cualquier otra dependencia de librerías dentro de tu aplicación. Simple, fácil de actualizar, y no tienes que lidiar con ningún archivo WAR en absoluto. Las configuraciones XML se restringen a lo más mínimo. Por el lado de la implementación, tanto Dropwizard como Spring Boot hacen uso de un gran JAR que incluye todos los JAR y sus respectivas dependencias en un único archivo, facilitando de esta forma la implementación con el uso de una sola línea.

Comunidad y fases de desarrollo

Dropwizard inicialmente fue lanzada por Coda Hale a fines del 2011, allá por sus días en Yammer. Desde entonces, 20 versiones han pasado, y actualmente está por la 0.8, disfrutando de mucho apoyo de la comunidad, siendo considerada la guía de referencia para las aplicaciones Java modernas. Por el lado negativo, se está enlenteciendo la aparición de nuevas versiones, que antes eran lanzadas cada un par de meses. En la versión 0.8, la más reciente, la mayoría de lo que vemos son arreglos menores y actualizaciones de versión de terceros. Actualmente, Dropwizard soporta Java 7 en adelante. Para usarlo con Java 8, puedes echar un vistazo a esta actualización parcial, para que puedas gozar de algunos de sus beneficios y nuevas funcionalidades (o si, por alguna razón, a ti no te gusta Joda-Time).

(EDITADO: Hay una lista exhaustiva de los módulos de Dropwizard, que puedes leer por aquí).

Hoy en día, puedes ver principalmente commits de Jochen Schalanda (EDITADO: y del equipo 0.8), con más de 160 colaboradores individuales y decenas de integraciones apoyadas por la comunidad, como dropwizard-extra, de Datasift. Entre las integraciones disponibles para Dropwizard, el soporte para Spring también está incluido. Una cosa más que definitivamente vale la pena que visites es el grupo oficial de usuarios, por aquí.

Con Spring Boot, respaldado por Pivotal, entrando al juego con la 1.0 en 2014, hay más de 40 integraciones oficiales (Starter POMs) para, básicamente, cualquier librería de terceros que se te pueda ocurrir. Esto lo incluye todo, desde los logs hasta integraciones con API sociales. Un nuevo proyecto Spring Boot que vale la pena mencionar aquí es JHipster, un generador Yeoman para Spring Boot y Angular.

En resumen, podríamos decir que Dropwizard tiene una comunidad más numerosa a su alrededor y Spring Boot goza de un mejor soporte oficial estructurado, junto con la actual base de datos de Spring.

Conclusión

  1. Si estás buscando entrar en el ecosistema Spring, inclinarte por Spring Boot probablemente sea la opción obvia. Más que únicamente una forma de acelerar el arranque de un aplicación Java RESTful, también actúa como un puente hacia Spring, por medio de integraciones con decenas de servicios. Quizás la auténtica pregunta aquí sea: ¿deberías empezar a fijarte en/volver a Spring? Lo cual sería, en sí mismo, todo un tema aparte para discutir. De otra forma, Dropwizard se adaptará mejor a tus necesidades.
  2. Un segundo asunto a tratar aquí es: ¿cuán dependiente eres tú de la inyección de dependencias? Si te decides por Guice, ir con Dropwizard y usar una de las integraciones de la comunidad puede ser una solución más sencilla, antes que seguir los pasos de Spring en la inyección de dependencias.
  3. Y, por último no menos importante, si lees el cuadro comparativo y pones las opciones frente a frente, ¿ cuál de los frameworks hace las mismas elecciones que tú harías si fueras a construir una aplicación desde cero? Ten en cuenta las elecciones por defecto, ya que pasar más tiempo configurando ese arranque, al final es ser infiel con el propósito que se tiene al usarlo.

Espero que esta comparación te haya sido de ayuda, y me agradaría leer tus comentarios sobre estos aspectos, así como saber cuáles factores fueron decisivos en tu decantación por una de estas alternativas.

Takipi shows you when and why your code breaks in production. It detects caught and uncaught exceptions, HTTP and log errors, and gives you the code and variable state when they happened. Get actionable information, solve complex bugs in minutes. Installs in 5-min. Built for production.

solve-button (1)

Further reading:

Java Garbage Collection

7 Things You Thought You Knew About Garbage Collection – and Are Totally Wrong  – read more

 

Bug line

5 Error Tracking Tools Java Developers Should Know – read more

02 (1)

15 Tools Java Developers Should Use After a Major Release – read more

 

email
Some kind of monster @ OverOps, GDG Haifa lead.
  • neo

    hola. el articulo esta en español pero en toda la web esta en ingles. ¿como obtengo los artículos en español?