Symfony 4: Microaplicaciones y monolitos

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

Uno de los debates más intensos en el mundo de la programación está relacionado con las aplicaciones tipo "monolito" frente a las micro-aplicaciones o micro-servicios. En el proyecto Symfony creemos que las dos formas de desarrollar aplicaciones son correctas (dependiendo de las circunstancias) y por eso Symfony soporta las dos.

Puede que la "Symfony Standard Edition" esté más pensada para desarrollar monolitos, ya el paquete symfony/symfony es una de sus dependencias. Este paquete es en realidad un "meta-paquete" que instala todos los componentes de Symfony y algunos de los bundles considerados como "core". Entre muchos otros, este paquete instala por ejemplo soporte para Twig y también el profiler. Pero si por ejemplo vas a desarrollar la API de tu nueva aplicación móvil, no necesitas nada de eso.

Obviamente tener en el directorio vendor/ algunos archivos de más que no utilizas no es un problema tan grave. Pero algunos programadores creen que sus aplicaciones están sobredimensionadas debido a esos pocos archivos de más. En cualquier caso, esto es más una percepción que una realidad.

El microframework Silex propone una forma de trabajar muy diferente en la que cada componente que se utiliza se carga explícitamente. ¿Supone esto que Silex es más simple, más ligero o más rápido que Symfony? No. Y sin embargo, Symfony 4 se va a parecer a Silex en esta forma de trabajar.

Aplicaciones Symfony minimalistas

Se acabó utilizar la dependencia symfony/symfony. Las aplicaciones Symfony ahora requerirán cada componente y cada bundle que vayan a utilizar. Este es probablemente el cambio más importante que vas a notar al desarrollar aplicaciones con Symfony 4. No obstante, este cambio no lo hemos hecho para que en el directorio vendor/ haya unos pocos menos archivos. En realidad, este cambio abre la puerta a todo un mundo de nuevas posibilidades.

Para empezar, permite la configuración automática de dependencias, que será uno de los puntos fuertes de Symfony 4. Cuando instales un bundle, Symfony lo configurará automáticamente por ti con una configuración por defecto adecuada. Y esa configuración se adapta dinámicamente en función de otras posibles dependencias que tengas instaladas en tu aplicación.

Considera por ejemplo el caso del FrameworkBundle. Alguna de sus funcionalidades, como los formularios, la validación, las plantillas, los assets, el serializer, etc. se pueden activar y desactivar.

En Symfony 3.2 los formularios están activados por defecto, aunque los puedes desactivar si no los vas a utilizar en la aplicación. ¿Por qué están activados por defecto? Porque Symfony no tiene ninguna manera de saber si vas a utilizar los formularios en tu aplicación o no. Desactivarlos por defecto empeoraría la experiencia de uso, porque sería otra opción más que debes aprender y configurar antes de poder probar tu primer formulario.

Ahora imagina que tienes una aplicación que no depende de symfony/symfony sino simplemente de symfony/framework-bundle. Activar/desactivar el soporte de formularios automáticamente ahora es trivial. Si la aplicación instala symfony/form, activa el soporte de formularios. Si no, desactívalo. Una solución simple, que no precisa de magia y tampoco requiere ninguna configuración. Una experiencia de uso increíble que va a hacer que te enamores de Symfony 4.

Una de las consecuencias de este nuevo comportamiento es que el rendimiento también mejora significativamente, ya que todas las funcionalidades que no utilizas están desactivadas. Sin tener que tocar nada ni optimizar ningún archivo de configuración. Pero ya hablaremos de benchmarks de rendimiento en otro artículo.

El nuevo minimalismo de Symfony hace que deje de tomar decisiones sobre tu aplicación y el entorno en el que se ejecuta. Por ejemplo, además de haber borrado los archivos LICENSE y README en la estructura por defecto de las nuevas aplicaciones, ahora tampoco verás ningún archivo .htaccess. ¿Y si utilizo Apache en mi proyecto? No te preocupes, porque en otro artículo te propondremos otra solución.

Composición

Eliminar la dependencia de symfony/symfony también permite implementar otra funcionalidad esencial de Symfony 4: descubrimiento automático de dependencias y borrado de dependencias. En el artículo anterior mencionamos el tema de la "composición" en vez de "herencia". Symfony 4 aprovechará la reducción de dependencias para utilizar "composición" en tus aplicaciones.

¿Quieres utilizar formularios? Pues instala la dependencia symfony/form. ¿Quieres usar el servidor web que trae PHP por defecto? Puedes instala la dependencia symfony/web-server-bundle. Las aplicaciones Symfony ahora mejoran progresivamente a medida que añades las dependencias que necesitas.

Si a esto le sumas la configuración automática, el resultado es realmente interesante. ¿Ya no necesitas el servidor web interno de PHP? Pues elimina el paquete symfony/web-server-bundle y Symfony se encarga de "desconfigurar" el bundle por tí (eliminarlo de AppKernel, borrar su configuración, etc.)

Otro buen ejemplo del cambio introducido por este nuevo paradigma es el bundle SensioDistributionBundle, que se instala automáticamente cuando usas la "Symfony Standard Edition".

Cuando se publica una nueva versión del bundle, algunos de sus archivos se copian directamente en la edición estándar de Symfony. Después tu tienes que eliminar todos estos archivos que no necesitas, y que incuso podrían ser potencialmente peligrosos en el servidor de producción, como por ejemplo web/config.php. ¿No te parece una forma un poco rara de hacer las cosas?

A nosotros si; por eso hemos movido toda esa lógica a un nuevo paquete llamado symfony/requirements-checker. ¿Quieres comprobar si tu ordenador está preparado para ejecutar aplicaciones Symfony? 1) Instala ese paquete con Composer; 2) ejecuta sus scripts; 3) corrige cualquier error reportado; 4) desinstala el paquete. Listo. Has comprobado los requerimientos y no has dejado ningún rastro en tu aplicación ni has tenido que configurar ni tocar nada.

La otra funcionalidad de SensioDistributionBundle consiste en ejecutar algunos scripts cada vez que ejecutas composer install or composer update. Por ejemplo, para crear el archivo bootstrap.php (que ya no hace falta si usas PHP 7), borrar la caché, instalar los assets, etc. Estos scripts se ejecutan mediante llamadas a Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::* en el archivo composer.json. De nuevo no parece la forma correcta de hacer las cosas. Así que en Symfony 4 hemos reescrito todo esto por completo de una manera más flexible. Ahora incluso puedes añadir tus propios scripts a Composer automáticamente.

Así que no vamos a publicar ninguna versión de SensioDistributionBundle compatible con Symfony 4. Ya no lo necesitamos. Piensa en "Symfony Flex" como una versión mejorada, más moderna y más poderosa de SensioDistributionBundle.

Adiós a los bundles en tus aplicaciones

Cuando publicamos la primera versión del documento Las Buenas Prácticas Oficiales de Symfony discutimos largo y tendido sobre si fomentar las aplicaciones sin bundles o con un solo bundle. Al final decidimos recomendar el uso de un único bundle llamado AppBundle para no hacer cambios demasiado drásticos. Además, en ese momento Symfony no estaba preparado para crear aplicaciones sin bundles de manera sencilla. Pero todo esto ha cambiado porque en los últimos meses hemos hecho muchos cambios para asegurarnos de que sea fácil crear aplicaciones sin bundles en Symfony 4.

Así que Symfony 4 no solo va a generar aplicaciones sin bundles sino que también va a recomendar que no crees bundles en tus aplicaciones. El código de tu aplicación ya no estará por defecto en un bundle llamado AppBundle sino en el directorio src/ de tu aplicación bajo el namespace App/. De nuevo, este cambio reduce la complejidad percibida por los programadores y hace que el código esté más desacoplado de Symfony. Personalmente no creemos que las aplicaciones tengan que estar 100% desacopladas del framework que utilicen (sea cual sea), pero desde Symfony 3.3 estamos haciendo más y más cambios para permitirte hacerlo si es eso lo que quieres.

Las aplicaciones sin bundles es una de las muchas nuevas buenas prácticas propuestas para Symfony 4. Y precisamente las buenas prácticas serán el tema del siguiente artículo.

Este artículo es una traducción del artículo Symfony 4: Monolith vs Micro publicado por Fabien Potencier.

Comentarios

Publicada el

5 de abril de 2017

Etiquetas

Proyectos Symfony destacados

La plataforma de eCommerce 100% Symfony que rivaliza con Magento y PrestaShop. Ver más

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