Antes de nada he de decir que este post es a título personal y que no represento y por supuesto no me ha contactado nadie para que hable a favor o en contra de esta solución. Seguramente alguno tendrá un punto de vista contrario al mío y por tanto le puedan parecer erróneas mis afirmaciones y por ello os animo a que comenteis y debatamos o pongamos nuestras opiniones a debate. Dicho esto comienzo con el post.

Es innegable que las arquitecturas orientadas a servicios (SOA) son una tecnología madura y muy útiles en el mundo de la Tecnología de la información (TI). La posibilidad de recurrir a servicios externos para gestionar ciertas partes de nuestros sistemas, junto con la capacidad de poder alternar entre diversos proveedores, es una ventaja a la hora de desarrollar nuestras soluciones.

Cuando necesitamos escoger la tecnología nos encontramos con las dos alternativas más frecuentes:

• SOAP
• REST

Aunque SOAP es la tecnología más antigua, REST es la más utilizada. La característica más distinguible entre ambas tecnologías es el lenguaje utilizado para el intercambio de información.

Mientras SOAP utiliza XML, REST utiliza JSON, lo que ya de por sí es una ventaja en cuanto a la cantidad de caracteres necesarios para enviar los mismos datos. Los seguidores del XML que abogan por los beneficios de este lenguaje auto-descriptivo estarán de acuerdo que, ante la necesidad de rapidez y reducción de bytes en el intercambio, el uso de JSON está muy por encima de las posibilidades que ofrece XML. El reducido tamaño de los JSON y la capacidad de los navegadores de tratar este formato de manera casi nativa, hace que los servicios REST se hayan convertido en la actualidad como la tecnología con mayor proyección en las SOA (arquitecturas orientadas a servicios).

Desde los comienzos de SOAP, la existencia de los ficheros WSDL (Lenguaje de descubrimiento de servicios web, pronunciado “güisdel”) permiten realizar un descubrimiento de los métodos ofrecidos por estos servicios. Estas definiciones permiten no solo conocer los métodos existentes, sino que describen tanto los parámetros de entrada como los resultados devueltos por dichos métodos. Todo ello ayuda a automatizar este tipo de servicios.

En cuanto a los servicios REST, se dispone de la iniciativa OpenAPI que tiene el mismo objetivo de proporcionar el catálogo de recursos de nuestra API, facilitando de esta forma el descubrimiento automático.

Pero como habréis leído en el título del post, hoy hablaré de las API y el framework de trabajo LoopBack.

APIs

No lo he comentado antes, pero supongo que muchos de vosotros estaréis familiarizados con las siglas API (application programming interface – Interfaz de programación para aplicaciones).

Resumiendo para aquellos que quizás no quieran forzar su mente recordando exactamente a qué me refiero, un API no es más que una especificaciones o definición (junto a la implementación) de métodos que tienen como objetivo tanto facilitar el desarrollo de aplicaciones, como disponer de mecanismos eficientes en el escalado de nuestras soluciones.

Si lo prefieres, podemos ver a las API como cajas negras en las que se desconoce cómo se hacen las cosas, mostrando únicamente los parámetros de entrada y cuál será la salida esperada. Todo esto tiene varias ventajas implícitas:

• Se puede dividir el trabajo entre diferentes equipos. Disponiendo de la especificación del API, todos pueden trabajar de forma totalmente independiente. Fijaros que el nivel de desacople es brutal, el equipo que desarrolla la solución y depende de esos métodos no requiere que estén operativo 100%, solo necesitará saber cuál es la naturaleza de las salidas y con esto ya puede trabajar, y el equipo que desarrolla el API no necesita saber para que será utilizado, simplemente produce la salida solicitada en base a unas entradas y claramente a una especificación.
• Agentes externos pueden desarrollar la especificación y las pruebas: Casi con total seguridad este trabajo lo realizará el consumidor del API para aquellos proyectos con una finalidad concreta, pero para las API de propósito general la definición de esta especificación será seguramente desarrollada por equipos especializados en dichas labores, dejando a los equipos de desarrollo la codificación del código. La existencia de tests de prueba podrán garantizar el buen funcionamiento del API antes de que este sea utilizado, pero ya sabéis que esto se ha de hacer no solo con las APis, sino con todo código que desarrollemos.
• En cualquier momento se puede migrar a otra solución más eficiente. Debido al desacople existente entre ambos mundos (la solución en sí y el API de servicios), los desarrolladores de una solución podrán irse por ejemplo a otro proveedor que ofrezca la misma salida ante las mismas entradas pero que además aporte algún beneficio adicional, por ejemplo más rapidez en la respuesta o menor coste en el uso.

Está claro que con la proliferación de servicios en Internet (la conocida nube), el aumento de estos servicios es creciente, lo que ofrece muchas posibilidades a la hora de dar solución a un problema.

APIs hay muchas y de muy diversa naturaleza. Fijaros que la solución que nos pueden aportar van desde algo tan completo como una gestión de base de datos, un sistema de reconocimiento de imágenes, almacenaje de información o algo más simple como información del tiempo, revisión ortográfica de texto, traducción, …

Lo importante es disponer de una buena especificación para empezar a utilizarlas.

Pero ¿Y si estamos en el otro lado?. ¿Que pasa si somos los desarrolladores de ese API?. Y aquí me centro solo en la parte de APIs WEB.

Como desarrolladores tenemos muchas posibilidades. Podemos crear nuestro propio sistema o podemos basarnos en algún framework o desarrollo previo.

Del primer caso ya hablaremos en otro momento, pero en el caso de utilizar alguno de los existentes aparece LoopBack como posible opción.

LoopBack: Construyendo APIs ¿asombrosas?

Tal y como reza la página principal de este Framework, LoopBack nos ofrece la capacidad de desarrollar APIs con una flexibilidad y estandarización muy elevada. ¿Es esto cierto?

Realmente las pruebas que he podido realizar muestran que el desarrollo de APIs es muy rápido. Además, al estar basado en el lenguaje TypeScript (ya sabéis, javascript tipado), la curva de aprendizaje no es muy elevada, aunque existe el cada vez más pequeño hándicap de requerir un Node.js para poder funcionar de forma adecuada.

Hace casi un año ya os comentaba que el Javascript estaba cogiendo mucha relevancia en el mundo de la programación, y con la llegada de Node.js el repunte ha sido mayor. La flexibilidad de este lenguaje es uno de los artífices de este crecimiento, pero no estamos aquí para hablar de Javascript.

Lo importante

Hay muchas cosas a tener en cuenta cuando se debe valorar la idoneidad de una nueva solución, y cada uno tendrá las suyas, lo que es totalmente respetable. Yo en mi caso me centro en 3 cuestiones:

• Rapidez de desarrollo
• Rapidez en la ejecución
• Documentación y comunidades

Como veis no valoro si es multiplataforma o el tipo de paradigma de programación que utiliza. Es totalmente lógico pensar que estas cuestiones son importantísimas a la hora de valorar un lenguaje de programación, pero en este caso no influyen en la decisión puesto que al ser una solución cerrada nos tendremos que adaptar a sus requerimientos.

Rapidez en el desarrollo

Como sabéis llevo años programando y por tanto este es uno de los aspectos que más valoro en un sistema. Cuando programamos es muy habitual tener que compilar, probar, modificar, compilar, probar, modificar, …. y así hasta un sinfín de repeticiones, lo que implica una mejor aceptación ante sistemas que me eviten algún paso o al menos me lo minimicen.

La primera ventaja que tiene este framework es que utiliza javascript o más bien typescript, por lo que la curva de aprendizaje es rápida. Por otro lado, el lenguaje javascript es muy ágil tanto a nivel de codificación como al de ejecución-modificación-ejecución, ya que al ser un lenguaje interpretado no requiere de tiempo de precompilado o compilado.

Pero, como he comentado, Loopback utiliza Node.js y por tanto requiere de un precompilado o traducción a lenguaje javascript. Esto implica que requerimos de un paso previo entre la modificación del código y la ejecución.

Por defecto el framework no dispone de ningún mecanismo automático que nos realice esta operación, teniendo que lanzar nosotros a mano el “build” del proyecto, lo que implica la detención del servidor y el arranque del mismo. Ya sé que existen mecanismos que podemos configurar para automatizar esto, pero nadie nos quitará el tiempo de compilación, detención y arranque del servidor y el refresco de nuestra web para probar los cambios realizados.

Si lo comparamos con un sistema en PHP, está claro que Loopback es más engorroso, pero la moda es la moda y al final uno se acostumbra (npm es la moda).

Además de la codificación, también es importante ver si el desarrollo de una solución es rápida, y en este aspecto así lo apuntan todas las pruebas que he realizado. Se que algunos y algunas estaréis pensando o diciendo ¿por qué no esperas a tener más pruebas y de esta forma hacer un análisis más preciso?, la verdad es que tenéis toda la razón, lamentablemente mi tiempo es escaso.

Rapidez de ejecución

Loopback es un framework diseñado para una tarea concreta, el desarrollo de APIs. Debido a esta especialización la ejecución es tan rápida y óptima como cabría esperar. Esta afirmación la hago a nivel de núcleo, claro está que la ejecución se irá deteriorando o ralentizando en función del código que desarrollemos y los módulos que carguemos.

Al igual que otros sistemas, el problema de lentitud del sistema final vendrá definido por el número de llamadas a funciones o sistemas externos. Conectarnos a bases de datos, realizar consultas con muchas tablas, integrarnos con otras APIs e incluso una mala optimización del código pueden favorecer una lentitud excesiva de nuestro sistema.

Lo bueno de usar un framework es que casi todos los problemas de lentitud seguramente estarán minimizados con el uso de plugins o módulos de terceras personas. Sin embargo, mi recomendación es siempre pensar en desarrollar o montar el sistema de la forma más óptima posible y luego, si acaso, añadir algún módulo adicional que nos haga ese plus adicional. Me refiero, claro está, a las famosas Caches.

En cuanto al núcleo en sí. Node.js es un sistema rápido y por tanto Loopback, o al menos su núcleo, también lo es, por lo que en este aspecto no hay ninguna objeción por mi parte.

Documentación y comunidades

Por último y no por ello menos importante, de hecho, algunos incluso dirán que este es el aspecto más importante, se encuentra la documentación y la comunidad de desarrollo que hay detrás.

Una buena o al menos correcta documentación nos permitirá desarrollar de forma adecuada nuestra solución. De nada sirve utilizar un sistema si no se conoce como operar con él.

Pero no solo la documentación es importante, la existencia de una comunidad de desarrollo o al menos un nutrido grupo de desarrolladores de esta tecnología nos puede sacar de muchos aprietos. ¿Nunca os ha ocurrido el ir a buscar un problema a internet y no encontrar nada al respecto? Pues lamentablemente a mí me ha pasado muchas veces y encontrarte con una tecnología nueva y ver que existe mucha gente que comparte información y ayuda al resto es una gozada.

Respecto a Loopback, dispone de una documentación actualizada y muy útil. Y en cuanto a las comunidades aún está muy por debajo de otras alternativas, pero al ser un producto joven está dentro de la normalidad.

En resumen, Loopback parece una alternativa a tener en cuenta si deseamos desarrollar un API de forma ágil y sin complicarnos mucho la vida. Eso sí, sin perder potencia y velocidad.

Si quieres que pruebe algún framework o producto indicamelo y veré si está de mi mano. No olvides dejar tu comentario, duda o sugerencia y nos vemos muy pronto.