Una breve historia inspiradora sobre Drupal desacoplado, Gatsby y Apollo

¿Mencioné que también mataremos al dragón de la búsqueda en tiempo real mientras mantenemos Drupal ultra-seguro frente a los orcos invasores? ¡Que comience la aventura!

Un día, nuestra heroína Alice usaba felizmente Drupal como API de backend, alimentando un constructor de Gatsby a través de JSON API. Bastante sencillo: Drupal era su fuente de verdad para su banco nacional. Pero Alice da soporte a muchos clientes internos, así que construía todos sus sitios estáticos cada noche. Durante todo el día, editores de esos clientes como Bob y Eve añaden cambios al contenido. Cuando Gatsby ejecuta la construcción, obtiene de Drupal, vía JSON, todos los datos que necesita para construir los sitios estáticos. Justo después, Gatsby desplegaba cada sitio estático en la nube. Hasta ahí, todo bien… !

Alice está feliz. Los sitios son extremadamente rápidos y eficientes. Pero Bob y Eve no están contentos. Porque agregan cambios, promociones y ediciones al contenido durante todo el día… pero ninguno de sus cambios aparece hasta el día siguiente… porque es entonces cuando ocurre la construcción de Gatsby. Los clientes del banco no ven nada de Bob ni de Eve hasta la siguiente construcción nocturna de Gatsby. Alice resuelve esto permitiendo disparar construcciones a demanda, y Bob y Eve vuelven a estar felices. Aun así, un dragón aterrador acecha en la oscuridad listo para atacar: no importa qué tipo de construcción, tarea cron o trabajo a demanda ocurra, Alice sabe que siempre habrá una ventana de tiempo durante la cual el contenido publicado que tiene Drupal será distinto del publicado en el sitio estático, y eso puede terminar causando problemas.

Alice les dice a los suyos, Bob y Eve, que no se preocupen. Pero entonces una nueva función asoma la cabeza: la búsqueda. Sí, quieren agregar búsqueda. Por la naturaleza de los sitios estáticos de Alice, tendrá que proporcionar un motor de búsqueda que recupere información para esos sitios. Pero aquí está el problema: ¿y si decidiera consultar la instancia de Drupal para obtener esa información? Si lo hace, Drupal se enfrentará a un buen desafío. Necesita excluir toda la información nueva (información nueva, o incluso nuevas versiones del contenido) en favor de recuperar exactamente la misma información que le entregó a Gatsby durante la última construcción. ¿Por qué? Porque si entregamos información sobre una promoción nueva que no formaba parte de la última construcción, y la rehidratación de Gatsby la usa para renderizar una tarjeta clicable que redirige al usuario a esa promoción, ¡producirá un 404! No es muy bueno para Alice ni para sus clientes, ¿verdad?

Resolver esto desde la perspectiva de Drupal exige mucho esfuerzo y procesos sincronizados. Por ejemplo, Alice podría exponer una API de búsqueda que solo incluya el contenido recuperado la última vez, dejando afuera el contenido publicado pero no recuperado. Al mismo tiempo, para las ediciones, Alice podría forzar al editor a crear versiones nuevas del contenido y, si recibe una consulta por ese contenido, devolver la versión que ya había entregado la última vez vía JSON API al consumidor de Gatsby. Aunque todo esto es factible, es demasiado complicado y, además, les dará a los clientes de Bob y Eve resultados potencialmente inexactos. ¿Y si la construcción de Gatsby termina bien, pero la publicación en la nube falla? Drupal dará por hecho que las últimas versiones del contenido ya están disponibles en la web, cuando no es así.

¡Qué dilema!

Y sin embargo, desde que Alice trabajó con nuestro equipo en Darwoft, tiene una forma ingeniosa de resolver este problema. La clave que encontramos es dejar de pensar la instancia de Drupal como la fuente de verdad de una versión particular del sitio estático en cualquier momento. Por supuesto, Drupal seguirá siendo la fuente de verdad de muchas áreas de datos del negocio, y será la fuente de verdad de cada construcción de Gatsby en el momento en que esa construcción ocurre, pero nada más que eso. Ten en cuenta el uso de una fuente de verdad asociada a un instante de tiempo en la frase anterior, que pasó casi desapercibido.

Alice se dio cuenta de que necesitamos empezar a considerar distintas fuentes de verdad, una por cada construcción. Cada vez que Gatsby recupera la información para construir el sitio, crea un “espejo” de la instancia de Drupal, y necesitamos asociar ese espejo a la construcción de ese momento en adelante. Esto es lo que en Darwoft llamamos la “fuente de verdad de la construcción”.

Una vez que tenemos este concepto en la cabeza, ¡el cielo es el límite!

Estamos usando la “fuente de verdad de la construcción” para alimentar sistemas de terceros, como servidores Apollo GraphQL y servidores de Elasticsearch, que nos darán la funcionalidad necesaria para proveer a nuestros sitios estáticos de contenido en tiempo real, mejorar la experiencia de usuario y soportar la funcionalidad de búsqueda.

Este enfoque resuelve el problema de Alice con algunas ventajas ingeniosas:

• Alice ya puede usar la instancia de Drupal detrás de una VPN, lo que reduce drásticamente la posibilidad de un ataque. Solo los editores con certificados de VPN y los agentes que ejecutan los procesos de construcción de Gatsby necesitan acceso a Drupal.
• Alice ya no necesita preocuparse por versionar el contenido en Drupal. Ni siquiera tiene que preocuparse por el contenido recién publicado. Drupal no está a cargo de indexar contenido ni de entregarles información a los usuarios en tiempo real. La responsabilidad de Drupal termina en el momento en que devuelve toda la información que Gatsby le pidió en algún punto del pasado.
• Tómate tu tiempo y respira hondo antes del siguiente: con este enfoque, Drupal podría ser usado por más de un proceso de Gatsby (o de cualquier otro framework). Este es un truco que sencillamente no era posible si Drupal tiene que llevar registro de qué contenido le entrega a cada consumidor.

¿Qué pasó al final? Bob y Eve quedaron felices. Alice consiguió un ascenso. Y el banco para el que trabaja conquistó toda su industria y salvó al mundo de la bancarrota y la perdición. ¡Contáctanos para conocer más historias geniales sobre heroínas técnicas valientes y trucos ingeniosos!

¡En Darwoft contamos historias sobre Drupal porque somos los héroes que matan a tus dragones, luchan por tus Alices y salvan tus proyectos! Para saber más, contacta a nuestro Managing Partner para el Pacific Northwest, Ned Hayes (ned.hayes@darwoft.io / 206-321-7981 - Seattle, Portland y más allá)