Un día, nuestra heroína Alice estaba usando Drupal como un API de backend alimentando a través de JSON API un constructor de Gatsby. Muy sencillo: Drupal era su fuente de verdad para su banco nacional. Pero Alice apoya a muchos clientes internos, por lo que creó todos sus sitios estáticos cada noche. Durante todo el día, los editores del cliente como Bob y Eve añaden cambios al contenido. Cuando Gatsby ejecuta la construcción, recupera todos los datos que necesita para construir los sitios estáticos de Drupal usando JSON. Justo después, Gatsby despliega cada sitio estático en la nube. Hasta ahora, 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 todo el día... pero ninguno de sus cambios aparece hasta el día siguiente... porque ahí es cuando sucede la construcción de Gatsby. Los clientes del banco no ven nada de Bob o Eve hasta la próxima construcción de Gatsby durante la noche. Alice resuelve esto permitiendo activar construcciones a demanda para que Bob y Eve estén felices nuevamente. Sin embargo, un aterrador dragón acecha en la oscuridad para atacar porque no importa qué tipo de construcción, trabajo cron o trabajo a demanda ocurra, Alice sabe que siempre habrá un período de tiempo durante el cual el contenido publicado que Drupal tendrá será diferente del publicado en el sitio estático, y eso puede acabar causando problemas.

Alice les dice a su gente – Bob y Eve – que no se preocupen. Pero entonces una nueva función levanta la cabeza: búsqueda. Sí, quieren agregar búsqueda. Debido a la naturaleza de los sitios estáticos de Alice, necesitará proporcionar un motor de búsqueda que recupere información para los sitios estáticos. Pero aquí está el problema: ¿y si decide consultar la instancia de Drupal para esa información? Si es así, Drupal enfrentará un bonito desafío. Necesita excluir toda la información (nueva información, o incluso nuevas versiones del contenido) a favor de recuperar exactamente la misma  información que entregó a Gatsby durante la última construcción. ¿Por qué? Porque si entregamos información sobre una nueva promoción que no formaba parte de la última construcción, y la rehidratación de Gatsby está utilizando eso para renderizar una tarjeta clicable redirigiendo al usuario a la nueva promoción, ¡producirá un 404! No es muy bueno para Alice o para sus clientes, ¿verdad?

Resolver esto desde la perspectiva de Drupal requiere mucho esfuerzo y procesos en sincronía. Por ejemplo, Alice podría exponer una API de búsqueda que solo incluya contenido recuperado la última vez, evitando contenido publicado pero no recuperado. Al mismo tiempo, para las ediciones, Alice podría forzar al editor a crear nuevas versiones del contenido y en caso de que reciba una consulta por ese contenido, podría recuperar la versión que proporcionó la última vez a través de JSON API al consumidor de Gatsby. Aunque todo esto es factible, es muy complicado y, al mismo tiempo, dará a los clientes de Bob y Eve resultados potencialmente inexactos. ¿Qué pasa si la construcción de Gatsby sale bien, pero la publicación en la nube falla? Drupal considerará que las últimas versiones del contenido ya están disponibles en la web, aunque no sea el caso.

¡Qué dilema!

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

Alice se dio cuenta de que necesitamos comenzar a considerar diferentes 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 esa instancia espejo con la construcción para ese momento. Esto es lo que nosotros en Darwoft llamamos la “fuente de verdad de la construcción”.

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

Estamos utilizando la “fuente de verdad de la construcción” para alimentar sistemas de terceros como servidores Apollo GraphQL y servidores de búsqueda elástica que nos brindarán la funcionalidad requerida para proporcionar a nuestros sitios estáticos contenido en tiempo real para mejorar la experiencia del usuario y apoyar la funcionalidad de búsqueda.   

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

• Alice ahora puede usar la instancia de Drupal bajo una VPN, lo que reduce drásticamente la posibilidad de piratería. Solo los editores que tienen certificados VPN y los agentes que ejecutan procesos de construcción de Gatsby necesitan acceso a Drupal.

• Alice ya no necesita preocuparse por versionar contenido en Drupal. Ni siquiera tiene que preocuparse por nuevo contenido publicado. Drupal no está a cargo de indexar contenido y/o recuperar información en tiempo real para los usuarios. La responsabilidad de Drupal termina en el momento en que recupera toda la información que Gatsby pide en algún momento del pasado.

• Tómate tu tiempo y respira profundamente para el siguiente: con este enfoque, Drupal podría ser utilizado por más de un proceso de Gatsby (o cualquier otro marco). Este es un truco que simplemente no era posible si Drupal necesita llevar un seguimiento de qué contenido recupera para cada consumidor.

¿Qué pasó al final? Bob y Eve estaban felices. Alice recibió una promoción. Y el banco para el que trabaja conquistó toda su industria y salvó al mundo de la bancarrota y la fatalidad. ¡Contáctanos para 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 tus dragones, luchan por tus Alices, y salvan tus proyectos.

Para saber más, contacta a nuestro Socio Gerente para el Pacífico Noroeste, Ned Hayes (ned.hayes@darwoft.io / 206-321-7981 - Seattle, Portland y más allá)