Netlify Edge Handlers are in Early Access (you can request it), but they are super cool and I think they are worth wrapping your brain around now. I think they change the nature of what Jamstack is and can be.
You know about CDNs. They are global. They host assets geographically close to people so that websites are faster. Netlify does this for everything. The more you can put on a CDN, the better. Jamstack promotes the concept that assets, as well as pre-rendered content, should be on a global CDN. Speed is a major benefit of that.
The mental math with Jamstack and CDNs has traditionally gone like this: I’m making tradeoffs. I’m doing more at build time, rather than at render time, because I want to be on that global CDN for the speed. But in doing so, I’m losing a bit of the dynamic power of using a server. Or, I’m still doing dynamic things, but I’m doing them at render time on the client because I have to.
That math is changing. What Edge Handlers are saying is: you don’t have to make that trade off. You can do dynamic server-y things and stay on the global CDN. Here’s an example.
- You have an area of your site at
/blogand you’d like it to return recent blog posts which are in a cloud database somewhere. This Edge Handler only needs to run at/blog, so you configure the Edge Handler only to run at that URL. - You write the code to
fetchthose posts in a JavaScript file and put it at:/edge-handlers/getBlogPosts.js. - Now, when you build and deploy, that code will run — only at that URL — and do its job.
So what kind of JavaScript are you writing? It’s pretty focused. I’d think 95% of the time you’re outright replacing the original response. Like, maybe the HTML for /blog on your site is literally this:
<!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>With an Edge Handler, it’s not particularly difficult to get that original response, make the cloud data call, and replace the guts with blog posts.
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="${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;
});
}(I’m hitting this site’s REST API as an example cloud data store.)
It’s a lot like a client-side fetch, except instead of manipulating the DOM after request for some data, this is happening before the response even makes it to the browser for the very first time. It’s code running on the CDN itself (“the edge”).
So, this must be slower than pre-rendered CDN content then, because it needs to make an additional network request before responding, right. Well, there is some overhead, but it’s faster than you probably think. The network request is happening on the network itself, so smokin’ fast computers on smokin’ fast networks. Likely, it’ll be a few milliseconds. They are only allowed 50ms of execution time anyway.
I was able to get this all up and running on my account that was granted access. It’s very nice that you can test them locally with:
netlify dev --trafficMesh…which worked great both in development and deployed.
Anything you console.log() you’ll be able to set in the Netlify dashboard as well:
Here’s a repo with my functioning edge handler.
The post Netlify Edge Handlers appeared first on CSS-Tricks.
You can support CSS-Tricks by being an MVP Supporter.
from CSS-Tricks https://ift.tt/39N4iVl
via IFTTT
No comments:
Post a Comment