¿Vale la pena construir tu propio framework en PHP?
¿Por dónde comenzar para construir un framework PHP?¿Por qué hacer uno cuando ya existen muchos y muy buenos?¿PHP?¿En serio? Todas estas preguntas son muy validas y espero que podamos resolverlas en las siguientes líneas. Comencemos con el “elefante” en la habitación (el que lo entendió, lo entendió).
¿Por qué PHP?
PHP sigue siendo un lenguaje muy usado, de fácil aprendizaje y ofrece todo lo que una aplicación Web puede requerir. Si tu aplicación Web va a requerir alto tráfico (y no, unos cientos de visitas al día no da para considerar como “alto tráfico”), está más orientada a lo que muestra (frontend) que lo que tiene por procesar (backend) o requiere un modelo distribuido a nivel mundial como el buscador de Google, quizás requieras otro modelo de desarrollo, pero para aplicaciones de baja o media complejidad, PHP es más que capaz de ofrecer una solución satisfactoria. Al final del día, no todo tiene que incluir Data Analytics o Inteligencia Artificial, por más que estén de moda.
¿Por qué un nuevo framework?
Respuesta corta: ¿Por qué no?
Calma, vamos a la respuesta larga.
Hace ya algún tiempo liberé una versión de un programa en PHP y no quedé del todo satisfecho. Buscando mejorarlo aprendí un poco de Laravel y algunas otras librerías como React y si bien me parecieron interesantes, no dejaban de incomodarme algunas de sus pretensiones. En la mayoría de estas librerías, si quisiera crear una página simple, digamos un “Hola mundo”, tendría que descargar una base de código que hasta hace unos meses (esto es, mayo/2024) rondaban tamaños en disco de:
- 63 MB para Laravel,
- 271 MB para Angular y
- casi 400 MB para React!
No se tú, pero a mi me parece mucho código de apoyo para un “Hola mundo”.
Me pregunto entonces, así como quien no quiere la cosa: ¿y si mi aplicación no requiere autenticación, acceso a bases de datos o comandos por consola, puedo descargar una base de código sin esas librerías? ¿Puedo removerlas manualmente si es del caso? Bueno, alguien tuvo la misma inquietud y preguntó en uno de los foros de Laravel si podía quitar los paquetes relacionados con React dado que no iba a usarlos. La respuesta de alguien en esa comunidad fue:
All of the packages installed by laravel are required for it to work as advertised. If you remove any, then some feature is no longer going to function as it should.
https://laracasts.com/discuss/channels/laravel/removing-unnecessary-packages
Traducción: “déjelo ahí quietico que por algo está”. Cierto, la respuesta tiene ya 3 años y mucho habrá cambiado desde entonces, pero de egos mejor no hablemos que en este mundo de la programación abundan. Ahora, dado que se usa composer para instalar Laravel, nada te impide usar dicha herramienta para retirar módulos no usados, pero con respuestas como la mencionada, quién querría arriesgarse, ¿verdad?
Todo esto me llevó a revisar mi programa y ver cómo mejorarlo, en lugar de migrarlo a alguno de dichos frameworks, eso si, aplicando algunas de los conceptos que aprendí de ellos. Entonces me di cuenta que lo que tendría al final sería un framework personalizado que podría reusar en futuros proyectos. Solamente quedaba “extraerlo” y crear una versión generalizada. Esto nos lleva a la primer pregunta formulada en este artículo: ¿Por dónde comenzar?
Nuevo framework, los primeros pasos.
Este proceso de adecuación y adaptación me parece es lo suficientemente interesante como para aprovechar y escribir un artículo o varios sobre el mismo. Empecé a documentar la adaptación del código usado para enrutar las consultas, pero mientras más avanzaba, más me enredaba con las librerías que debía usar como soporte. Explicar cada una de ellas tomaría bastante tiempo y haría que un artículo sobre ese código Router fuera excesivamente extenso. Bajé un poco las pretensiones y decidí empezar con un módulo más sencillo, uno usado para presentación de errores en pantalla. De nuevo se estiró la vaina. Así que al final, la conclusión fue que lo mejor era empezar por algo más simple, por las bases.
Bien dicen los mayores (y a mi edad esa afirmación ya me incluye) que “primero hay que aprender a caminar antes de empezar a correr”. Bueno, vamos a por ese paso a paso… en un próximo artículo. Este ya se hizo bastante extenso, ¿no crees?
Ya para terminar, veamos un pequeño teaser, qué podemos esperar en ese próximo artículo:
- Uso de patrón Singleton para implementar servicios comunes a todo el proyecto.
- Creación de una función “autoload” para cargar los scripts que definen Clases PHP.
- Librería de soporte (helper) para recuperar información relativa al servicio Web consultado.
require_once 'miframe/commons/helpers.php';
// Imprime contenido de $_SERVER['REQUEST_METHOD']
echo miframe_server()->get('REQUEST_METHOD');¿Y qué hay de ti? ¿Cómo puedes aportar a este proyecto? Bueno, puedes compartir en los comentarios cosas como:
- Tus expectativas sobre un framework como el planteado, para desarrollos de baja o media complejidad.
- ¿Qué módulos consideras debería incluir este framework? o
- Simplemente dar un “ánimo, me gustaría ver a dónde lleva todo esto” :)
Recuerda ese último punto, tu acompañamiento y ánimo son el principal insumo en proyectos como estos. No siendo más, nos vemos pronto con esos “primeros pasos”.
El momento correcto para empezar no es mañana o la próxima semana, sino ahora
— Anónimo
También puedes leer este y otros artículos en mi Blog de programador.
Y si te interesan otras lecturas no técnicas, te invito a conocer uno de los cuentos incluidos en mi libro “Grandes momentos de instantes cotidianos” siguiendo este enlace.
Y ahora si, no siendo más por el momento, nos vemos próximamente.
