Como una librería me obligó a programar toda una API. Parte I: El nacimiento.
Hola, mi nombre es Juan José Ramos y programo en PHP
En la cabeza de algunos resonará una frase:
Hola Juanjo!
Sí, así, al más puro estilo de una reunión de alcohólicos anónimos.
Y es que es complicado quitarse el estigma de ser programador en PHP. Como su misma definición impone: una marca en el cuerpo, especialmente grabada a fuego, como signo de infamia.
Bromas a parte, PHP es un lenguaje al que le cuesta quitarse la etiqueta de antiguo y de precursor de malas prácticas. Un lenguaje con mucho recorrido (la primera versión data de 1995), pero que hoy en día se sigue utilizando en un porcentaje muy alto de las aplicaciones web que se encuentran activas en Internet.
¿Y por qué esta introducción tan extensa? ¿Qué os quiero contar?
Pues que debido a su largo recorrido, si te especializas en este lenguaje de programación es muy probable que la refactorización sea una de las tareas con las que te vas a cruzar en tu vida profesional, sí o sí.
El maldito email precursor de la acción ¶
Un día como otro cualquiera al llegar a la oficina. Son las 8:00 y lo primero que haces al llegar, es abrir tu cliente de correo (no has visto tu correo desde las 17:00 del día anterior), y un mensaje entre tantos llama tu atención:
Hola Juanjo, han detectado un fallo de seguridad en la versión de la librería PHPMailer que tienes en tu código fuente
Mi proveedor de hosting me prepara el desayuno que viene cargadito de tostada con tomate y bien servido de refactorización.
Todavía no era consciente de lo que la actualización de la librería iba a implicar. PHPMailer se utiliza dentro de la plataforma en decena de lugares y la instanciación de la librería está repartida por muchos lugares dentro del código (o al menos eso intuía).
Mi primera visita a Google ¶
Lo primero que se te pasa por la cabeza es que simplemente tienes que actualizar la librería, repasar que todos los emails se envían correctamente y a volar. Una tarea ardua en sí pero que no conlleva más que la tediosa tarea de investigar desde donde se lanzan emails en toda la aplicación.
Lo primero es lo primero, vamos a ver qué versión de la librería está implementada en código. Visitamos la famosa carpeta \includes
, apuntamos mentalmente la versión y a visitar a nuestro amigo Google.
Está bastante desactualizada, llevo 2 años trabajando en esta aplicación y por mi parte no ha habido actualización. Era de esperar.
Lo que no era de esperar es que cuando visito el repositorio oficial de PHPMailer, me encuentre con que para poder actualizar a la siguiente versión de PHPMailer tenga que actualizar mi versión de PHP también.
¡Bam! Tiro al pecho.
Nunca me he enfrentado a una actualización de la versión de PHP, mucho menos en una aplicación tan extensa y compleja; pero esto ser tornaba mucho más difícil aún, y es que para aquellos de vosotros que no lo sabéis, PHP sufrió un gran cambio entre la era PHP5 y la era PHP7, y sí, lo que estáis pensando es lo que tenemos entre manos.
La aplicación está programada en PHP5 y la librería PHPMailer me obligaba a tener a menos la versión PHP7.
El nacimiento de mi primera API REST en producción ¶
La pregunta: ¿Y ahora que hago? pasó fugazmente por mi cabeza. La respuesta: Pues liarme la manta a la cabeza, no queda otra.
Tenía entre manos tres opciones:
- Actualizar PHP5 a PHP7: totalmente descartable por la extensión del código y la gran incompatibilidad entre funciones que se utilizan en cada una de ellas.
- Cambiar la librería que gestiona el envío de correos: otro hueso duro de roer. Ya estoy familiarizado con la asignación de propiedades de la librería y sus métodos. ¿Me compensa buscar y tener que instalar una librería distinta? Además, si quiero tener esta otra librería actualizada, tendrá que ir montada sobre un PHP más moderno.
- Crear una API REST que gestione el envío de emails: ya había programado una API REST en un side project hace unos meses y estaba deseando poder plasmar mis conocimientos en una aplicación en producción. !Me quedo con esta opción!
¿Qué elementos voy a necesitar para crear una API REST? ¶
Aunque ya tenia práctica en esto de las API REST gracias a mi side project, ahora tocaba meter las manos en el barro de verdad.
En estos momentos siempre me gusta coger papel y boli y ponerme a listar todos los elementos que voy a necesitar, la lógica desacoplada de las librerías especificas a utilizar cuando me ponga ‘manos al teclado’. Todos estos elementos pasaron por mi cabeza:
Siempre ando de cabeza con el tema de los includes, requires, etc. El código se vuelve un lío a la hora de saber qué archivo incluir dónde. Esto tenía fácil solución: tengo que crear un namespacing.
La gestión de rutas en un sólo archivo es importante. Es lo que denominamos endpoints y son las diferentes puertas de entrada a la aplicación desde el exterior.
No podía faltar aplicar una de las buenas prácticas que más me gusta, el contenedor de dependencias. Se trata de un contenedor que alberga todo tipo de instanciaciones listas para usar. Que tu aplicación contenga con contenedor de dependencias no es solo bueno porque tenemos todos los objetos recogidos en un sólo archivo, sino porque además facilita la inyección de dependencias en las llamadas a los métodos, haciendo mi código ‘tipado’ pero con las clases que yo mismo creo.
También tengo que tener en cuenta elementos como:
- La seguridad: no todo el mundo debería poder acceder a mi API.
- Middlewares: que facilitan que el código se ejecute antes del acceso a una ruta o la aplicación entera.
- Variables de configuración en un solo archivo: para esto nada mejor que utilizar las variables de entorno, algo que tenía fácil creando un .env en el raíz y una librería que las gestione.
Manos a la obra ¶
Tras un primer análisis (en el que no siempre se tiene en cuenta lo que nuestra aplicación va a necesitar), ahora toca ponerse manos a la obra y escoger el lenguaje de programación y batería de librerías a utilizar.
Esto lo veremos en un siguiente episodio de esta saga de creación de una API.
Mientras tanto descubre como crear una API con SlimPHP o cómo hacer tests de API con Postman en nuestros cursos. Todo el poder de una API contado de tal forma que tú también podrás crear una. Ver más en la Zona Premium.
Escrito originalmente por: Juan José Ramos
Daniel Primo
12 recursos para developers cada domingo en tu bandeja de entrada
Además de una skill práctica bien explicada, trucos para mejorar tu futuro profesional y una pizquita de humor útil para el resto de la semana. Gratis.