Ir al contenido principal

¿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?

Vamos ahora 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 (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, ¿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.

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?

Antes de 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.

¿Cómo puedes aportar a este proyecto? Compartiendo 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

La imagen de portada corresponde a un montaje sobre una foto de Patrick Tomasso de Unsplash

Comentarios

Entradas populares de este blog

Manejo de recursos HTML para tus páginas web con PHP

Déjame saber si te resulta familiar esta situación: páginas web que descargan el mismo recurso (sean estilos CSS o código Javascript) más de una vez o incluyen recursos remotos que tardan una eternidad en cada descarga. Yo lo he visto en más de una ocasión y no es difícil imaginar el porqué ocurre. Un desarrollador incluye el recurso de estilos que necesita su segmento de código y otro hace lo mismo, sin reparar (o sin que siquiera importe) que comparten el mismo recurso. En otro escenario muy común, acostumbran incluir muchos recursos remotos, con lo que el rendimiento de la página depende de lo rápido que responda dicho recurso. ¿Puede hacerse algo al respecto? Claro que si. Vamos a crear una clase en PHP que se encargue de administrar estos recursos y que nos facilite su despliegue en la página sin repeticiones . ¿Y respecto a la demora en la carga de recursos remotos? Atendamos una cosa por vez, porque como dicen por ahí: «Vísteme despacio, que tengo prisa». Administrando ...

Manejo de clases globales únicas en PHP

¿Cómo acceder desde cualquier script en tu proyecto a Clases y/o funciones de uso común? Este puede ser una de las primeras directrices a establecer para cualquier proyecto porque siempre, siempre , sea en  PHP  u otro lenguaje, será necesario usar recursos comunes. En PHP existen diferentes alternativas para su manejo, ya sea por medio de variables globales o de clases/objetos estáticos. A continuación consideraremos una propuesta para este manejo. Creación de recursos globales Para ilustrar esta solución, partimos de la necesidad de implementar una librería para manejo de servicios relacionados con el servidor Web, que de forma amigable nos permita disponer de información como: Valores almacenados de la variable superglobal $_SERVER de PHP. Valores asociados a la consulta realizada por el usuario, por Ej. la dirección IP del usuario o la URL ingresada. Valores asociados al servidor web usado, por Ej. la dirección IP del servidor o la ubicación del script que ej...

¿Qué tan bueno es realmente el “foreach” en PHP?

Como toda buena historia, esta comienza hace algún tiempo. El que fuera mi jefe por allá en la primera década del 2000, realmente odiaba (y mucho) el uso del foreach en el código PHP . Prefería que usáramos alguna alternativa diferente, alguna combinación del  for o del while . ¿Por qué? Ve tú a saber, nunca fue abierto respecto a las razones de su aprensión hacia ese constructor propio del lenguaje. Pero antes de continuar, veamos qué es y para qué nos puede servir. Arreglos, tenían que ser arreglos ¿Qué es foreach ? De acuerdo al manual de PHP , su definición es la siguiente: El constructor foreach proporciona un modo sencillo de iterar sobre arrays . foreach funciona sólo sobre arrays y objetos , y emitirá un error al intentar usarlo con una variable de un tipo diferente de datos o una variable no inicializada. Para su uso correcto existen dos sintaxis validas, a saber: foreach (expresión_array as $value) { ... } foreach (expresión_array as $key => $value) { ....