Nuestro granito de arena a la comunidad Javascript: passport-google-one-tap
En Genially, el 99% de nuestra base de código es Javascript y, aunque sea un dato difícil de calcular, es muy probable que apenas el 20% de ese código haya sido escrito por nuestro equipo. Obviamente, con esta afirmación no pretendo restar valor a los excelentes profesionales que me acompañan cada día en esta aventura, sino que lo que me gustaría es ensalzar a la gran comunidad que existe alrededor de este lenguaje y cómo ésta ha sido capaz de generar un ecosistema donde reutilizar código y compartir conocimiento sea tan fácil.
Innumerables son los memes sobre la cantidad de frameworks que se generan cada día en el universo Javascript y no pocos los que se mofan de alguna que otra situación difícil que hubo que superar, porque para qué negarlo, a veces abusamos del uso de dependencias. Pero todo esto no es más que el reflejo de que la comunidad de Javascripters es numerosa, activa y repleta de gente dispuesta a compartir, y en Genially queremos seguir formando parte de ella. De hecho, queremos hacerlo de una forma más activa.
Una pequeña aportación
Hace unos días hemos liberado un pequeño paquete de software que llevamos semanas usando en producción. Se trata de passport-google-one-tap, una estrategia para PassportJS que permite integrar este middleware de autenticación para Node.js con Google One Tap, el nuevo mecanismo de registro ideado por el gigante de Mountain View.
Somos conscientes de que no es algo revolucionario, ni comparable a esos grandes proyectos Open Source como son React, Cypress o tantos otros que utilizamos en Genially cada día. Pero tenemos la certeza de que ayudará y facilitará el trabajo a otras personas, tal y como nos han ayudado a nosotras otros pequeños proyectos sin los cuales este ecosistema no sería igual.
No es la primera aportación de código libre de la empresa, pero sobre todo, esperamos que tampoco sea la última. Esta nueva librería no salda la deuda que tenemos con la comunidad ni mucho menos, con todo lo que ésta nos ha dado eso sería una tarea imposible, pero con ella, desde el equipo técnico, queremos hacer una demostración de intenciones y que sirva de ejemplo a otros proyectos internos que se quisieron liberar y que por diversas razones se quedaron en el camino. Tal vez, ahora que estamos viviendo una nueva e ilusionante fase como compañía, podamos recuperarlos.
Las motivaciones y los porqués
Los que nos conocen y nos visitan habitualmente saben que hemos dado recientemente un buen lavado de cara a la web. Destacan notablemente el diseño, las animaciones y los fantásticos copys que han realizado nuestros equipos de marketing, diseño o contenido entre otros; pero también se dieron otros cambios que, aunque no tan visibles de cara al usuario, tienen una gran relevancia en nuestra plataforma.
Uno de esos cambios ha sido la creación de un servicio centralizado de autorización para todos nuestros aplicativos basado en PassportJS. Entre otras cosas, esta librería nos ha facilitado la tarea de integrarnos con proveedores de identidad de terceros, pero había uno que nos interesaba que no estaba en su lista: Google One Tap. Así que nos pusimos manos a la obra, la creamos y… ¡a producción! Enseguida nos dimos cuenta de que acabábamos de crear algo que tenía las características ideales para ser liberado:
Ya lo tenemos hecho y funciona. Probablemente sea la característica más importante ;)
Es algo que seguro que se va a utilizar por otras personas y otras empresas. PassportJS es un actor de sobra conocido en el mundo de Node.js y Express, estamos hablando de una librería que tiene más de un millón de descargas semanales; Google One Tap es, en cambio, un proveedor de identidad nuevo, pero tan en auge que está siendo integrado en aplicaciones tan conocidas como Linkedin o Twitter. No nos cabe duda de que le hemos facilitado el camino a alguien, y eso, siempre es motivo de alegría.
Es un proyecto al que le vamos a poder dar soporte. Lanzar un proyecto Open Source implica normalmente cierta responsabilidad sobre el mismo. Solicitudes de nuevas funcionalidades, correcciones de bugs, actualizaciones… El tiempo es limitado y no queremos lanzar algo que luego no podamos cuidar, pero al ser éste un proyecto tan pequeño y acotado, consideramos que no tendremos ningún problema en darle el soporte que se merece.
En otros contextos puede que tenga sentido planificar de antemano que una pieza de tu software va a ser liberada, en nuestro caso, como os he comentado, ha sido más bien una cuestión de oportunidad. Lo bueno, es que hemos tenido el apoyo de la empresa desde el principio para poder hacerlo y no hemos necesitado convencer a nadie de que liberar software puede ser algo beneficioso como compañía.
El proceso
No hay nada como decir que algo “ya está hecho” para a continuación darte cuenta de todo lo que aún queda por hacer. Teníamos una clase escrita en Typescript de unas 150 líneas que queremos liberar y hemos acabado publicando en Github un repositorio en el que se pueden contar más de 12.000 líneas de texto. Si estamos más o menos familiarizados con la publicación de un paquete de NPM, sabemos que liberar código supone algo más que colgar un fichero en algún servidor. Voy a enumerar algunos de los pasos que tuvimos que dar:
Lo primero fue crearle un repositorio propio. En Genially trabajamos principalmente en un monorepo y con workspaces de Yarn. La clase a liberar no era más que un fichero en uno de los proyectos de este repositorio privado, así que el primer paso estaba claro.
Una vez aislada la clase te das cuenta de que tienes que mover o replicar bastantes cosas que tienes en tu proyecto ya configuradas y que muchas veces has olvidado porque simplemente funcionan:
- El documento de definición de paquete: package.json. En este caso hay que hacer uno nuevo, así como mover cualquier dependencia requerida. En nuestro caso dependemos de google-auth-library.
- El sistema de compilación. Ya he comentado que usábamos Typescript, y a la hora de publicar tiene que ser Javascript. Teníamos la opción de reescribir la clase o traernos la configuración de TS. Optamos por lo segundo, solo que además tuvimos que cambiar ciertos parámetros para que la librería fuese lo más usable posible: que tuviese source maps, emitiese ficheros de tipos y ampliar lo máximo la versión mínima Node.js.
- El análisis de código estático. Usamos Eslint para esta labor en nuestros proyectos, así que de nuevo otra configuración que migrar.
- Los tests. Esta pieza la consideramos infraestructura en nuestro proyecto interno, y lo cierto es que no solemos realizar tests unitarios en estos casos, así que no los tenía. Pero, al aislar el proyecto y ofrecerlo a otras personas pensamos que era algo necesario y lo hicimos (más aún, teniendo en cuenta que Jared Hanson, creador de PassportJS, publica todas las estrategias oficiales con un 100% de cobertura).
- Un ejemplo de uso real. Cuando hemos necesitado usar una estrategia hecha por terceros la hemos implementado fácilmente gracias a que nos han aportado ejemplos de uso. No queríamos ser menos en este aspecto y también hemos construido un ejemplo de aplicación Express completa que puedes encontrar en el propio repositorio.
- La documentación. No solo ha habido que añadir un README que sirva como introducción al uso de la librería, también ficheros que expliquen cómo contribuir al proyecto, su licencia o plantillas para pull requests o reportes de bugs.
- Integración continua. Utilizando Github Actions se ha configurado el repositorio para que tanto el linting como los tests se ejecuten automáticamente en cada commit a la rama principal o en cada pull request. Además se ha automatizado la publicación del paquete al registro público de NPM cada vez que se crea una release en Github. Como estos ficheros de configuración son parte del repositorio, puedes consultarlos y adaptarlos a tus necesidades si tú también estás pensando en publicar un paquete de Node.js a través de este sistema.
Espero que se pueda apreciar el cariño que le hemos puesto a este pequeño trabajo.
Gracias
Para finalizar darte las gracias a ti por haber leído hasta aquí, a Jared Hanson por haber creado esa herramienta que tanto trabajo nos ha facilitado, a todo el mundo que con su tiempo y esfuerzo ha colaborado de cualquier manera en un proyecto de software libre o de código abierto y, cómo no, a todos los genios y genias que utilizan Genially cada día.
