Symfony 4: Componer en vez de heredar

Symfony 4 se publicará en Noviembre de 2017. Esta serie de artículos explica sus principales novedades:

Symfony 3.0 fue la versión más aburrida de la historia de Symfony, ya que simplemente era una versión "limpia" de Symfony 2.8:

Symfony 3.0 = Symfony 2.8 - funcionalidades obsoletas

Symfony 4.0, que además va a requerir PHP 7.0 como mínimo, será muy diferente:

Symfony 4.0 = Symfony 3.4 - funcionalidades obsoletas + una nueva forma de desarrollar aplicaciones

Además, mientras pensaba qué debíamos cambiar para Symfony 4, también pensé en qué podíamos cambiar para mejorar el día a día del desarrollo de aplicaciones Symfony. El resto del artículo explica todas esas mejoras.

Instalar bundles es aburrido

La mejor manera de añadir nuevas funcionalidades en las aplicaciones Symfony es instalar bundles y librerías mediante Composer.

De hecho, Composer surgió a partir de una discusión sobre cómo instalar bundles, plugins, extensiones, etc. en Symfony y phpBB. Lo extraño es que ni Symfony ni phpBB utilizan Composer para instalar sus bundles, plugins, extensiones, etc.

Cuando instalas un bundle de Symfony, no basta con ejecutar un comando de Composer. Antes de poder utilizarlo, tienes que activar y configurar el bundle. Estos son los pasos que normalmente debes seguir:

  1. Ejecutar a mano composer require symfony/bundle para elegir exactamente el paquete que quieres instalar. Sin embargo, si estamos dentro del contexto de una aplicación Symfony, debería ser mucho más sencillo instalar funcionalidades. Por ejemplo: ¿por qué no ejecutar composer req mailer para instalar un mailer o composer req admin para instalar un admin generator?
  2. Registrar el bundle en la clase AppKernel.
  3. Opcionalmente, registrar las rutas del bundle.
  4. Configurar el bundle (al menos añadir su configuración inicial para activarlo).

El primer paso no se puede automatizar, pero ¿qué pasa con el resto? Por ejemplo, puede que la configuración no se pueda automatizar completamente, pero sí que sería posible definir una configuración inicial para el bundle.

Desinstalar un bundle es todavía más aburrido

En las aplicaciones Symfony que evolucionan con el tiempo, es común tener que borrar bundles que ya no utilizas. En teoría es muy fácil hacerlo: composer remove symfony/bundle. En la práctica no es tan sencillo.

Para desinstalar un bundle tienes que deshacer todos los cambios que hiciste al instalarlo: eliminarlo de la clase AppKernel, borrar sus rutas, eliminar su configuración, etc. Como tienes que tocar cosas en varios archivos, borrar un bundle no solo es aburrido sino que es fácil cometer errores.

La edición "Symfony Standard" no es suficiente

Las "distribuciones Symfony" fueron un intento de minimizar estos problemas mediante aplicaciones complejas de Symfony listas para usar.

La distribución más popular es la "Symfony Standard Edition", que está pensada para facilitar el desarrollo tradicional de aplicaciones web, en las que utilizas una base de datos, plantillas, un mailer, etc. Sin embargo, cabe preguntarse si esta forma "tradicional" de crear aplicaciones sigue vigente hoy en día. Por ejemplo, ¿y si quieres desarrollar una aplicación tipo micro- framework? ¿Y si desarrollas servicios web o APIs?

La "Symfony Standard Edition" toma las decisiones en lugar del programador, pero siempre son o demasiadas decisiones o demasiado pocas. Así que las distribuciones Symfony no son una buena idea en la práctica, ya que no facilitan realmente el proceso de añadir y eliminar funcionalidades.

Otro problema de las distribuciones es que incluyen archivos que no necesitas, como por ejemplo los archivos LICENSE y README. La mayoría de proyectos que desarrollas en el trabajo no utilizan una licencia de código abierto, así que ¿para qué incluir este archivo?. Lo mismo pasa con el archivo composer.json: tienes que cambiar la mayoría de sus contenidos para adaptarlos a tu proyecto de empresa.

Puede que borrar uno o dos archivos sea fácil, pero el problema es que pronto tendrás que eliminar más cosas.

Por ejemplo, hace unos años la "Symfony Standard Edition" incluía un pequeño bundle de prueba (el famoso AcmeDemoBundle). Como no era sencillo eliminar completamente este bundle, tuvimos que dejar de incluirlo. Y esta decisión fue tan buena como mala. La "Symfony Standard Edition" empeoró porque los programadores ya no tenía un ejemplo del que poder aprender. Pero a la vez mejoró, ya que esos mismos programadores no tenían que perder el tiempo borrando ese bundle de prueba.

¿No te ha convenido esta explicación? Pues echa un vistazo al README de la distribución REST:

¿Dónde están el resto de distribuciones Symfony?

Posiblemente debido a todo lo anterior, la idea de las distribuciones Symfony nunca se popularizó. Aparte de la "Standard Edition" no hay ni una sola distribución Symfony que sea popular. De hecho, en symfony.com solo listamos tres distribuciones.

Las distribuciones no son suficientemente flexibles. No puedes cambiar de una a otra. Además, tienes que usar o todas sus funcionalidades o ninguna y no pueden evolucionar.

Las distribuciones de Symfony son una abstracción equivocada. No necesitamos una aplicación compleja ya creada y lista para usar. Lo que necesitamos es un mecanismo sencillo para hacer que una aplicación pueda crecer.

La experiencia de uso ideal

Como programadores, lo que queremos es empezar de la manera más sencilla posible, sin apenas dependencias. Pero también queremos poder hacer crecer nuestras aplicaciones de una manera simple cada vez que lo necesitemos. Algo así como empezar tipo micro-framework y crecer, si queremos, hasta un monolito gigante. El framework que utilices (en este caso, Symfony) no debería impedir este crecimiento.

En definitiva, crear un proyecto desde cero con Symfony o hacer crecer un proyecto es demasiado difícil para los que están empezando y demasiado pesado para los que son expertos. Podemos hacerlo mejor.

Mejor "composición" que "herencia"

Si te paras a pensar, las distribuciones de Symfony usan el equivalente de la "herencia" de código. La mayoría de ellas son forks de la edición estándar de Symfony a la que le han añadido más bundles. ¿Y si utilizáramos "composición" en vez de "herencia"? Por ejemplo, quiero usar una distribución REST, pero combinarla con la distribución del admin generator. O mejor aún, ¿y si nos olvidamos de las distribuciones Symfony para siempre?

Aquí es donde entra Symfony Flex, una nueva forma de crear aplicaciones Symfony y hacerlas crecer.

Symfony Flex permite crear aplicaciones Symfony muy fácilmente, tanto si es una micro aplicación como si es una mega aplicación con docenas de dependencias. Además, instala y desinstala bundles automáticamente. También añade una configuración por defecto para los bundles. Por último, también te permite descubrir los mejores bundles.

Symfony Flex será la herramienta por defecto para gestionar las aplicaciones Symfony 4. Pero si quieres, Symfony Flex también se va a poder utilizar para gestionar las aplicaciones Symfony 3.3 y 3.4. En cualquier caso, ten en cuenta que Symfony Flex es todavía una aplicación alpha, así que su funcionamiento podría cambiar ligeramente de aquí a Symfony 4.

En el siguiente artículo de esta serie, te contaré más sobre Symfony Flex. Mientras tanto, puedes echar un vistazo a la nueva estructura de las aplicaciones Symfony creadas con Symfony Flex. Quizás no te esperabas que la estructura por defecto estuviese completamente vacía, ¿verdad?

Este artículo es una traducción del artículo Symfony 4: Compose your Applications publicado por Fabien Potencier.

Comentarios

Publicada el

3 de abril de 2017

Etiquetas

Proyectos Symfony destacados

La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.