Bien, ese es un título poco atractivo para una publicación de weblog, pero tenga la seguridad de que el contenido compensa con creces esta oscuridad.
Recientemente, mi juguete favorito en el mundo, Contenedor del servidor de Google Tag Supervisorintrodujo la capacidad de manejar operaciones asincrónicas en variables.
Esto se hace a través de una interfaz JavaScript conocida como Promesa. A Promesa es una forma de ejecutar código en JavaScript sin saber cuál será su valor last. La parte de “promesa” de este concepto significa que el código promesas que eventualmente alcanzará un valor, por lo que otro código que dependa de este valor pueda ejecutarse en consecuencia.
En esta actualización reciente, API de etiquetado del lado del servidor Se han actualizado para manejar las promesas.
Lo que esto significa en la prácticaes que puedes adjuntar una variable a una etiqueta, hacer que esa variable devuelva una Promesa de completar una operación asincrónicay la etiqueta esperar automáticamente que la Promesa resuelva antes de completar su trabajo.
¿Y qué?, te oigo preguntar. finalmente puedes enriquecer los flujos de datos que pasan a través de un contenedor de servidor ¡sin tener que crear Clientes y Etiquetas personalizados para ello!
Solo tenga en cuenta que todo lo que veremos en este artículo requiere implícitamente que utilice o cree plantillas personalizadasya que Google Tag Supervisor del lado del servidor no tiene una opción de “variable JavaScript personalizada” para ejecutar código advert hoc.
X
El boletín a fuego lento
Suscríbete al Boletín a fuego lento para recibir las últimas noticias y contenido de Simo Ahava en su bandeja de entrada de correo electrónico.
¿Qué ha cambiado?
Anteriormente se procesaban variables en Google Tag Supervisor sincrónicamente.
Esto significaba que cuando el tiempo de ejecución de GTM comenzaba a analizar una variable, la ejecutaba fila por fila hasta llegar a un return declaración en el contexto de ejecución. Luego, ese valor se devolvió a cualquier fuente que haya invocado la variable en primer lugar.
Si la variable intentó ejecutar un asincrónico operación, lo que significa que hizo algo que eventualmente devolver un valor pero no cuando la variable se ejecutó sincrónicamente, la variable simplemente devolvería un undefined valor porque GTM no esperaría a que se completara la variable.
Con este cambio, las variables ahora pueden devolver un Promesa, que el código de ejecución espera resolver antes de continuar. En otras palabras, la variable no tiene que resolverse en un valor inmediatamente; puede devolver una promesa solemne de que eventualmente alcanzará un valor (por supuesto, dentro de un plazo determinado). se acabó el tiempo).
¿Y por qué es esto tan importante? Porque hasta ahora, si quisieras tener tu etiquetas y Clientela Espere alguna operación asincrónica, tuvo que incrustar estas llamadas asincrónicas en la etiqueta/código del cliente.
Ahora todo lo que tiene que hacer es asegurarse de que la variable devuelva una Promesa, y lo que sea que llame a la variable esperará diligentemente a que esa Promesa se resuelva o rechace.
Cómo trabajar con promesas
Afortunadamente, no tienes que preocuparte por la interfaz de Promise en sí.
Aunque tú poder usa el nuevo Promise API para crear promesas personalizadas, y los programadores más experimentados ciertamente pueden hacer uso de Promise.all Para encadenar varias Promesas, muchas API de etiquetado integradas del lado del servidor se han actualizado automáticamente para utilizar la interfaz de Promise.
He aquí un ejemplo de uso Promise.all en una plantilla variable:
// Run a number of API calls and return a single Promise that is resolved when all of the API calls have resolved
const Promise = require('Promise');
const sendHttpRequest = require('sendHttpRequest');
return Promise.all((
sendHttpRequest(FIRST_API_URL, FIRST_API_OPTIONS),
sendHttpRequest(SECOND_API_URL, SECOND_API_OPTIONS)
)).then(outcomes => {
// outcomes will equal ({statusCode: 200, headers: {}, physique: ...}, {statusCode: 200, headers: {}, physique: ...});
if (outcomes.filter(consequence => consequence.statusCode === 200).size === 2) {
return "Each API calls executed efficiently!";
} else {
return "Oops, one thing went unsuitable!";
}
});
Cómo han cambiado las API existentes
El BigQuery, sendHttpGety sendHttpRequest API (y el nuevo API de Firestore!) probablemente sean los que más utilizará en este nuevo contexto. Le permiten ejecutar solicitudes HTTP asincrónicas a puntos finales (como su API de enriquecimiento) y la respuesta se puede usar para enriquecer los flujos de datos de sus etiquetas y de sus Clientes.
Para trabajar con ellos, sólo necesita utilizar la nueva sintaxis suitable con Promise. Si está ejecutando esto en una variable, recuerde que la variable debe devolver la promesa. El valor de retorno actual se establecerá en lo que el Los métodos de instancia de promesa finalmente regresan.
Promete tiempo de espera después de 5 segundos. si no se resuelve ni se rechaza. Si la API tiene su propio tiempo de espera establecido (como el
sendHttpRequest), entonces eso se respetará.
A continuación se muestra un ejemplo de cómo abordaría una solicitud GET easy. Esta API sondea el API pública de Circle.so y devuelve la cantidad de miembros de la comunidad para los que se crea el token de autenticación.
const sendHttpRequest = require('sendHttpRequest');
const JSON = require('JSON');
const AUTH_TOKEN = 'XXXXXXXXXXXXX';
const API_URL = 'https://app.circle.so/api/v1/community_members';
const OPTIONS = {
headers: {Authorization: 'Token ' + AUTH_TOKEN},
technique: 'GET',
timeout: 2000
};
// Return the Promise
return sendHttpRequest(API_URL, OPTIONS).then(success_result => {
const members = JSON.parse(success_result.physique);
// When the Promise resolves (efficiently), the size of the array within the response physique is returned
return members.size;
});
Las promesas tienen tres métodos:
.then()toma dos funciones como parámetros (aunque arriba solo uso la primera). El primero es por lo que sucede cuando la Promesa se resuelve exitosamente, y el segundo es por lo que sucede cuando la Promesa se rechaza..catch()toma una sola función como parámetro y se ejecuta si se rechaza la Promesa. Esta es una forma práctica de aislar el código sólo para la resolución de errores..lastly()toma una sola función como parámetro, y es siempre ejecutada ya sea que la Promesa haya sido resuelta o rechazada.
Entonces, en el ejemplo anterior, solo me concentro en resolución exitosapero también podría agregar un .catch() paso allí para manejar los problemas. Sin embargo, como se trata de una solicitud GET easy, no veo ninguna razón para tratar específicamente los casos de error, por lo que estoy de acuerdo con que la variable regrese undefined en caso de que se encuentre con un error.
Almacenamiento en caché
Para evitar que se realice la misma llamada API una y otra vez, existe una almacenamiento en caché mecanismo en su lugar. El caché tiene como alcance la solicitud entrante, por lo que una vez que ingresa una nueva solicitud al contenedor del servidor, el caché se restablece.
El caché sólo funciona si la respuesta es almacenable en caché. En otras palabras, el caché no es forzado en recursos que no deben almacenarse en caché.
Si desea agregar almacenamiento en caché adicional con más management, puede utilizar el templateDataStorage API para esto.
Recuerde que todas las solicitudes salientes se consideran salida de purple tráfico por el servicio en la nube y deberá pagar por el uso de esa purple. Por lo tanto, es muy importante implementar el almacenamiento en caché, de una forma u otra.
Una cosa que yo amar Lo que hay que ver es la opción de anular el objeto de datos de evento producido por el Cliente con estas variables asincrónicas. De esa manera, podría agregar las variables de enriquecimiento al propio objeto Datos de evento y estarían disponibles para todas las etiquetas, activadores y variables que utilizan este objeto.
Esto también solucionaría completamente el problema del almacenamiento en caché, porque la variable se ejecutaría solo una vez: cuando se resuelva en el objeto Datos de evento.
Resumen
Aunque esta ha sido una descripción basic muy técnica, espero que vea la promesa (juego de palabras) de esta actualización del Administrador de etiquetas de Google del lado del servidor.
Enriquecimiento del flujo de datos ha sido una de las cosas en las que he estado insistiendo como un punto de venta único de una solución de administración de etiquetas del lado del servidor, así que estoy muy contento de haber finalmente tiene una forma práctica de hacerlo. Ha sido dos años ¡Desde que se anunció públicamente el etiquetado del lado del servidor en GTM, después de todo!
Ahora la pelota está en el tejado de la comunidad.
¡Sea creativo con esas plantillas variables!
Quiero ver el Galería comunitaria relleno con variables de utilidad para sondear diferentes API, manejar comunicaciones HTTP y ejecutar operaciones asincrónicas para enriquecer aquellos Clientes y etiquetas que podrían beneficiarse de ellas.
¿Qué opinas de este lanzamiento? ¿Puede pensar en casos de uso en los que estas nuevas Promesas podrían resultar particularmente útiles?