Front.id

¿Qué es un drupal desacoplado?

En pocas palabras se trata de tener dos aplicaciones diferentes, una para el front, normalmente con un framework de javascript (vuejs, react, angular...) y otra para el back, que es nuestro drupal.

En algunas ocasiones los roles encargados de la edición de contenidos y la administración general de la herramienta, reutilizan la parte de administración de drupal para no tener que hacer toda esa parte en la aplicación de frontend. Si es algo que solo van a ver "los de casa" se puede explicar que hay dos aplicaciones y así nos ahorramos un montón de trabajo.

¿Qué problemas resuelve desacoplar el frontend del backend?

El principal problema que resuelve es la libertad a la hora de utilizar el HTML que los frontend quieran. Es decir, no obligamos a los frontend a utilizar el HTML que nos generan módulos tan útiles (para backend) como views, webform, paragraph, etc. A pesar de que todas las plantillas se pueden sobreescribir, la experiencia nos hace ver que muchos frontend terminan cansados de sobreescribir plantillas hacer preprocess, etc.

Con una aplicación desacoplada, todo esto se termina, los frontend hacen toda la aplicación con tecnologías en las que se sienten cómodos (HTML, Javascript y el generrador de CSS de turno) y solo interaccionan con el backend para pedirle los datos a la API. Incluso pueden tener una API que devuelva datos ficticios para hacer todo su trabajo y establecer esa API como "contrato" para que los backend hagan su trabajo a la vez y que nadie dependa de nadie.

Otro gran problema que resolvemos es que tenemos mucho más control sobre las URL que publicamos. Seguramente a muchos nos habrá pasado que creamos una taxonomía, o una entidad X para categorizar cosas dentro de un contexto determinado. Las entidades que creamos posiblemente no tengan sentido por si solas, en cambio tenemos una URL pública para poder "ver" ese elemento. Hay muchos mecanismos para que esa URL no sea accesible o simplemente no exista, pero muchas veces nos la dejamos abierta hasta que llega google, la indexa y alguien nos dice "tenemos una página desmaquetada" (OF!).

Desacoplando tenemos mucho más control sobre este tipo de cosas, porque hay que crear las rutas.

Hay más ventajas, pero la red está llena de charlas y artículos en los que se cuentan las bondades de este sistema y no quiero que este artículo sea uno más.

¿Qué problemas te crea desacoplar el frontend de drupal?

Este tipo de arquitecturas te resuelve unos problemas pero te crea otros, por lo que hay que elegir bien qué problemas podemos afrontar más fácilmente para decantarnos por una opción.

Hay que mantener dos infraestructuras

Esto es sencillo, si tenemos el backend en un dominio y el frontend en otro, tenemos que tener las dos aplicaciones corriendo, posiblemente en dos máquinas y seguramente con dos pilas tecnológicas completamente diferentes.

Si nos preocupa el SEO de nuestro frontend tendremos que hacer Server Side Rendering (que la primera respuesta de nuestro frontend venga en HTML ya montado para que los buscadores lo indexen) por lo que el servidor del front estará seguramente sirviendo Node JS, y el de drupal PHP.

Esto es trivial si tenemos un buen equipo de sistemas, pero también nos complica los despliegues cuando hay cambio de API si no la estamos versionando muy bien o no tenemos cuidado con la caché para la aplicación de frontend (recuerda que el javascript se cachea en el navegador).

Vamos a echar de menos cosas que nos hace drupal

• Cuando queramos un sitemap.xml de nuestro sitio no nos valdrá con instalar el módulo.
• Cuando queramos controlar las metatags de nuestros contenidos vamos a tener que montarnos un sistema para inyectarlas correctamente en la aplicación de frontend.
• Cuando tengamos que generar ficheros descargables, por ejemplo un PDF o un CSV que dependa del usuario validado, el frontend va a tener que hacer de proxy con el fichero que genere el backend, porque nuestra aplicación estará validada en el drupal, pero nuestro navegador no, por lo que no podríamos llamar directamente a una URL de nuestro drupal.
• La autenticación con nuestra cuenta de google, twitter o facebook, se complica bastante porque los módulos de drupal que hacen que esto sea trivial actúan sobre el dominio donde está drupal.
• Los famosos mensajes de alerta y notificaciones de drupal, es algo que normalmente no tenemos en cuenta a la hora de estimar, pero ahora es un componente más a realizar.
• Tenemos que ocuparnos de ocultar enlaces a cosas que no tenemos acceso.
• ... Seguramente más cosas, pero estas son las que yo he echado de menos en los proyectos que he hecho de forma desacoplada.

Los sistemas de autenticación no son triviales

No son una complicación muy grande, pero hay que tener en cuenta que los sistemas de autenticación seguros no siempre son fáciles de implementar.

Por poner un ejemplo, con oAuth2, los token expiran cada poco tiempo y hay que renovarlos.

"Pues se renuevan con el token de renovación"

Claro, pero hay que tener en cuenta que esto se produce en cualquier momento, y mientras estás renovando el token puede que el usuario haga más peticiones a la API. Tenemos que ser transparentes para que el usuario no note que algo que no tiene por qué entender está ocurriendo ahí dentro.

Esto se soluciona con una pequeña cola que se active en el momento en que recibamos un error de token expirado y que se mande de nuevo para que se resuelvan todas las promesas en cuanto lo tengamos renovado.

Tiene solución pero es otro problema que nos vamos a encontrar.

Hay que afinar la seguridad de nuestra API

Ahora tenemos una API expuesta al público sobre la que se pueden autenticar los servicios, por lo que hay que configurar bien CORS.

También hay que tener en cuenta que de serie no vamos a tener el mecanismo de flood que hace que si un usuario falla varios intentos de autenticación en poco tiempo tenga que esperar un rato para poder hacer login.

TL;DR

Antes de tirarte de cabeza a hacer drupal desacoplado piensa bien a qué vas a renunciar y qué vas a ganar. Puede que no merezca la pena, o puede que si.