Controladores de borde Netlify | Programar Plus

Controladores de borde de Netlify están en acceso anticipado (puedes solicitarlo), pero son geniales y creo que vale la pena que los revises ahora. Creo que cambian la naturaleza de lo que Jamstack es y puede ser.

Conoces las CDN. Son globales. Alojan activos geográficamente cerca de las personas para que los sitios web sean más rápidos. Netlify hace esto para todo. Cuanto más puedas poner en un CDN, mejor. Jamstack promueve el concepto de que los activos, así como el contenido renderizado previamente, deben estar en una CDN global. La velocidad es uno de los principales beneficios de eso.

La matemática mental con Jamstack y CDN tradicionalmente ha sido así: estoy haciendo concesiones. Estoy haciendo más en tiempo de compilación, en lugar de en tiempo de renderizado, porque quiero estar en esa CDN global por la velocidad. Pero al hacerlo, estoy perdiendo un poco el poder dinámico de usar un servidor. O todavía estoy haciendo cosas dinámicas, pero las hago en el momento de renderizar en el cliente porque tengo que hacerlo.

Esa matemática está cambiando. Lo que dicen los Edge Handlers es: no tiene que hacer ese intercambio. Puede hacer cosas dinámicas de servidor y permanecer en la CDN global. He aquí un ejemplo.

  1. Tiene un área de su sitio en /blog y le gustaría que devuelva publicaciones de blog recientes que se encuentran en una base de datos en la nube en algún lugar. Este Edge Handler solo necesita ejecutarse en /blog, por lo que configura el controlador Edge solo para que se ejecute en esa URL.
  2. Escribes el código a fetch esas publicaciones en un archivo JavaScript y ponerlo en: /edge-handlers/getBlogPosts.js.
  3. Ahora, cuando compile e implemente, ese código se ejecutará, solo en esa URL, y hará su trabajo.

Entonces, ¿qué tipo de JavaScript estás escribiendo? Está bastante enfocado. Creo que el 95% de las veces estás reemplazando por completo la respuesta original. Como, tal vez el HTML para /blog en su sitio es literalmente esto:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Test a Netlify Edge Function</title>
</head>
<body>
  <div id="blog-posts"></div>
</body>
</html>

Con un Edge Handler, no es particularmente difícil obtener esa respuesta original, hacer la llamada de datos en la nube y reemplazar las agallas con publicaciones de blog.

export function onRequest(event) {
  event.replaceResponse(async () => {
    // Get the original response HTML
    const originalRequest = await fetch(event.request);
    const originalBody = await originalRequest.text();

    // Get the data
    const cloudRequest = await fetch(
      `https://css-tricks.com/wp-json/wp/v2/posts`
    );
    const data = await cloudRequest.json();

    // Replace the empty div with content
    // Maybe you could use Cheerio or something for more robustness
    const manipulatedResponse = originalBody.replace(
      `<div id="blog-posts"></div>`,
      `
        <h2>
          <a href="https://css-tricks.com/netlify-edge-handlers-2/${data[0].link}">${data[0].title.rendered}</a>
        </h2>
        ${data[0].excerpt.rendered}
      `
    );

    let response = new Response(manipulatedResponse, {
      headers: {
        "content-type": "text/html",
      },
      status: 200,
    });

    return response;
  });
}

(Estoy usando la API REST de este sitio como un ejemplo de almacén de datos en la nube).

Es muy parecido al lado del cliente. fetch, excepto que en lugar de manipular el DOM después de la solicitud de algunos datos, esto sucede antes de que la respuesta llegue al navegador por primera vez. Es un código que se ejecuta en la propia CDN (“el borde”).

Entonces, esto debe ser más lento que el contenido CDN previamente renderizado, porque necesita hacer una solicitud de red adicional antes de responder, ¿verdad? Bueno, hay algunos gastos generales, pero es más rápido de lo que probablemente piensas. La solicitud de red se está produciendo en la propia red, por lo que las computadoras ultrarrápidas en las redes ultrarrápidas. Probablemente, serán unos milisegundos. De todos modos, solo se les permite 50 ms de tiempo de ejecución.

Pude poner todo esto en funcionamiento en mi cuenta a la que se le otorgó acceso. Es muy bueno que pueda probarlos localmente con:

netlify dev --trafficMesh

… que funcionó muy bien tanto en desarrollo como en implementación.

Cualquier cosa que tu console.log() también podrá configurar en el panel de Netlify:

Aquí hay un repositorio con mi controlador de borde en funcionamiento.

(Visited 5 times, 1 visits today)