Episode 87 - Netlify Edge Functions with Eduardo Bouças

Episode Description

Eduardo Bouças from Netlify explains edge functions, their evolution from edge handlers, the partnership with Deno, and practical use cases for running code closer to users.

Episode Summary

In this episode, Netlify software engineer Eduardo Bouças joins to discuss Netlify's edge functions product, then in public beta. The conversation begins with Eduardo's background growing up fascinated by computers and the internet, eventually gravitating toward developer tooling, which led him to Netlify and the Jamstack ecosystem. He explains edge functions as an evolution of serverless computing where code runs in multiple locations worldwide, closer to end users, resulting in faster experiences. Eduardo traces the product's lineage from Netlify's earlier edge handlers, explaining that the team pivoted away from a proprietary runtime in favor of partnering with Deno, driven by a commitment to open web standards. The discussion covers practical use cases including middleware patterns for A/B testing, authentication layers, geolocation-based content personalization, and response modification. Co-host Christopher Burns shares his own experience using edge functions for regional pricing on a marketing site. Eduardo details how edge functions integrate into the existing Netlify CLI workflow, automatically pulling in the Deno binary and even configuring VS Code for developers. The episode closes with a candid discussion about whether edge functions will replace traditional serverless functions, with Eduardo and the hosts agreeing that full replacement depends on the broader ecosystem, particularly edge databases, catching up to make a fully distributed stack practical.

Chapters

00:00:00 - Eduardo's Background and Path to Netlify

Eduardo Bouças introduces himself as a software engineer at Netlify, recounting how his love of coding began as an only child fascinated by computers and the early internet. He describes learning HTML and FTP as a kid and pursuing that passion through a computer engineering degree into a career as a developer spanning front-end and full-stack PHP and MySQL work.

Over time, Eduardo discovered his real passion was building tools for other developers rather than shipping end-user products. A role focused on enabling his engineering team made the connection click, and he began seeking opportunities in developer tooling. That search aligned naturally with Netlify and the Jamstack paradigm, where he could combine his interest in open web development with building platforms that make developers' lives easier.

00:03:06 - What Are Edge Functions and Why the Edge Matters

Anthony asks Eduardo to define edge computing and explain why developers should care about running functions there. Eduardo frames edge functions as part of the serverless family, with the key distinction that code executes across multiple global locations rather than a single centralized server, reducing latency by serving users from nearby infrastructure.

The conversation then turns to the history behind Netlify's approach. Eduardo explains that the earlier edge handlers product used a proprietary runtime, which conflicted with Netlify's commitment to open standards. This led the team to partner with Deno, whose Rust-based, web-standards-focused runtime was a natural fit. Anthony and Eduardo also touch on the broader momentum around Deno, including the Web Interoperable Runtimes Community Group, as a sign that the ecosystem is rallying around open, portable edge runtimes.

00:08:04 - Use Cases: Middleware, A/B Testing, and Geolocation

Eduardo walks through the practical differences between serverless functions and edge functions, highlighting the middleware pattern as a key differentiator. Unlike traditional serverless functions that always terminate a request, edge functions can intercept requests on the way in or modify responses on the way out, enabling use cases like A/B testing, JWT-based authentication layers, and dynamic content transformation.

Christopher Burns shares a real-world example from his own company, where edge functions detect user geolocation to display country-specific pricing on a marketing website. Eduardo confirms that Netlify exposes geolocation data to every edge function and expresses excitement about what the broader community will build with these primitives, emphasizing that building on open standards means developers aren't locked into Netlify-specific patterns.

00:13:41 - Why Deno: Runtime Choices and TypeScript Support

The hosts ask Eduardo to explain why Netlify chose Deno over other options. Eduardo points to Deno's Rust-based performance optimizations, its design for distributed infrastructure, and its approach of pulling dependencies via URLs rather than a centralized package manager as key factors that aligned with Netlify's goals around openness and performance.

Eduardo also highlights Deno's first-class TypeScript support, noting developers need no build step or transpilation. When asked about compatibility with Deno Deploy, Eduardo says he believes there is feature parity, meaning developers could potentially lift and shift code between the two platforms. Anthony contextualizes this as a major step toward solving the portability problem created by multiple proprietary edge runtimes from providers like Cloudflare and Fastly.

00:21:00 - Developer Experience and CLI Integration

Anthony asks how edge functions fit into the existing Netlify developer workflow. Eduardo explains that running netlify dev now supports edge functions alongside serverless functions, with the CLI automatically downloading and caching the Deno binary so developers never need to install Rust or Deno tooling themselves. He describes a thoughtful VS Code integration that detects edge function files and offers to configure the editor to distinguish between Node and Deno TypeScript contexts.

The broader conversation centers on the philosophy of making complex technology feel effortless. Eduardo argues that developers often underestimate how much friction comes from installing and configuring multiple tools, and that providing smart, useful defaults while preserving flexibility for power users is essential. Anthony draws a comparison to how Redwood bundles Prisma, noting that reducing setup overhead is one of the most impactful things a platform can do for adoption.

00:26:43 - Getting Started and Framework Integrations

Eduardo outlines the hello-world path for edge functions: create a project, add a JavaScript or TypeScript file that exports a default function receiving a standard Request and returning a standard Response, and configure which route it runs on. He emphasizes that this API contract is intentionally minimal and standards-based, with Netlify-specific features isolated in a separate context object to preserve portability.

Anthony notes that the Netlify site already lists adapters for Next, Nuxt, Svelte, and Remix, and teases upcoming Redwood integration work. Eduardo confirms that Netlify has published documentation giving framework authors the primitives needed to build their own edge function adapters, further opening the ecosystem to community-driven integrations and extending the reach of edge computing across the meta-framework landscape.

00:31:01 - Will Edge Functions Replace Serverless Functions?

Christopher poses the big question: should everyone just migrate to edge functions? Eduardo offers a nuanced take, noting that the massive Node ecosystem and its library of packages means many developers will continue relying on traditional serverless functions. He also raises the centralized database problem, questioning whether edge execution truly benefits applications that still call back to a single-region database.

The hosts and Eduardo agree that the future depends on the rest of the infrastructure stack catching up. Christopher envisions a world where files, functions, and databases all live at the edge, making location transparency the default. Eduardo concurs, saying the technology to run at the edge exists today, but the ecosystem of supporting services isn't fully there yet. The episode wraps with Eduardo inviting listeners to connect on Twitter and continue the conversation about edge computing's evolving role in web development.

Transcript

00:00:00 - Eduardo Bouças

Yeah, that sounds good.

00:00:13 - Anthony Campolo

Eduardo, welcome to the show.

00:00:14 - Eduardo Bouças

Hey, thanks. Great to be here.

00:00:16 - Anthony Campolo

You are a software engineer at Netlify, and you've been doing a lot of work on Netlify Edge Functions. You got onto our radar because Jason Lengstorf tweeted, "Hey, if anyone wants to talk about edge functions, you should get Eduardo on your podcast." And we've talked about edge functions a couple of times on the show, so I jumped at that opportunity. So thank you to Jason for that rec. And before we get into all that, though, we would love to just hear a little bit about you, how you got into coding, and how you got into Netlify.

00:00:46 - Eduardo Bouças

Yeah. First of all, thanks for the invite, and thanks to Jason as well. I hope I can live up to Jason's expectations. It's a tall order. My name is Eduardo. Like I said, I'm a software engineer. I got into coding very early on. I was a small kid, and I was super interested in computers. I was an only child, you know, just sitting at home with the computer was pretty much my life growing up as a kid. And then I was exposed to the internet, and that kind of changed my life. I was amazed that you could build a website and connect with people all over the world. And then I quickly became interested in how you actually build these things. Then I started learning the basics, HTML and how to push files to a server over FTP and things like that. At that time, I started to create this idea in my mind that, when I grew up, it would be cool to do this as my job.

00:01:41 - Eduardo Bouças

And that's kind of how it unfolded. My path from that point on was chasing this idea of, "I want to do computer things when I grow up." So then I did a computer engineering course, and I started working as a developer. I actually started doing a little bit of front-end and a little bit of, I guess it's called, full-stack development, doing a bunch of PHP and MySQL back in the day. Then I had the opportunity to try a bunch of different things, a bunch of different technologies, and different kinds of parts of the stack. And then, at some point in my career, one of the jobs that I had was less about building solutions for the end customer and more about building things for my team and enabling a team of developers to work better. I think that's when things really clicked for me, and I realized that I wanted to work on developer tooling. I wanted to build things for developers, because building things on the web is not always easy.

00:02:42 - Eduardo Bouças

So there's a lot of work that we could do to make that easier, and that's what excites me. And that's, I think, kind of what led me to Netlify, because the whole Jamstack paradigm was something that also clicked very well with me, and I was exploring that, and it felt like the perfect place to kind of marry those two interests and to build tooling for developers who are interested in that paradigm. Yeah, that's how I ended up where I am.

00:03:06 - Anthony Campolo

Let's get into edge functions. We've talked about this a couple of times on the show, so why don't we start off with just a general definition of what the edge is, and why we'd want our functions to be there?

00:03:20 - Eduardo Bouças

So if people are familiar with the concept of serverless computing, the idea that you can deploy a piece of code that will run somewhere on a server without you having to actually provision that server and worry about server configurations, managing traffic, and adding security patches and things like that, it's this idea that you have this isolated and self-contained piece of code, and that will exist somewhere in the cloud and respond to requests. I kind of see an edge function as being part of that family, part of that paradigm, with the difference that it runs at the edge. And what's the edge? It's this idea of running in multiple locations spread around the world, which creates the opportunity to run this code closer to your users. That will allow you to create faster experiences, because you don't have to hit a server somewhere in us-east-1 or something. You'll actually be talking to servers that are closer to where you are. And that's the idea, an evolution or another step in the serverless paradigm, but running closer to where people are consuming that data from.

00:04:34 - Anthony Campolo

I'm also curious, kind of from a more historical angle. I know that Netlify had something called Edge Handlers going back over a year ago now, and now there are these things called Edge Functions. And I remember when Edge Handlers first came out, Matt was on a podcast, SE Daily, talking about how they were using Deno for it. So I think there is some connection between these two things. I'm not sure exactly what that connection is. So are these the same things? Are these a revamped version of those? Were those an early test case for these? What is the relation between those Edge Handlers and the Edge Functions that we have today?

00:05:13 - Eduardo Bouças

Yeah, that's a great question. So Edge Handlers, as you said, over a year ago, we'd identified that being able to program the edge was something very powerful, and we wanted to bring those capabilities to our customers. We started working on Edge Handlers, which was our solution for that. But we realized after a while that we were maybe solving the problems that our customers had, but we weren't necessarily moving the ecosystem in the right direction, because we were effectively building our own edge runtime, our own walled garden. We really believe, like I personally believe, and I know that Netlify as a company believes in this as well, in the open web and open source and open standards. And we would hate to ask someone to build their entire business on top of this proprietary software. That's why we took a step back and decided to revisit our plans. Edge Functions is really the culmination of that process of revisiting our initial solution. Now, with Edge Functions, we looked around and asked ourselves, what could be an open runtime for edge computing that is built on web standards, that is built with openness at its core?

00:06:37 - Eduardo Bouças

I think it became clear to us that Deno was the answer to that. And so we partnered with Deno, and we built Edge Functions on top of the Deno runtime. That was the next evolution of our initial Edge Handlers effort.

00:06:53 - Anthony Campolo

Okay, yeah, that's really cool. Especially as someone who has been following Deno for a while. I've been really interested in Deno, kind of just because I find the narrative of it really interesting. Like, you know, the creator of Node comes back and makes a new Node that's even better than the first Node. You know, I like that. I think that kind of framing is juicy. But from a pure tech angle, for a while I didn't really see anyone picking up Deno, either for personal projects or just kind of in the ecosystem, and that seems to have really changed. Deno seems to really be taking off, and they announced something recently, the Web Interoperable Runtimes Community Group. So I'm curious if this is something that Netlify is also involved in, or if this is something that you've been watching as well, and if this kind of plays into that whole Deno-as-a-more-universal-runtime narrative.

00:07:43 - Eduardo Bouças

It definitely aligns with that vision. We're super excited to see that effort, because that's just proof that there's an appetite for making this an open runtime for edge computing. That's the approach to building for the web that we want to be involved with and that we think will push the ecosystem forward. We're super excited to see that, definitely.

00:08:04 - Anthony Campolo

So why don't we get into some use cases? I think we've talked a little bit about what this is and the context and history around it, but we always like to talk about actual use cases here. So why would someone do this? What are actual reasons that a developer would want to put an edge function in their project?

00:08:22 - Eduardo Bouças

So I think, to better answer that question, it's worth talking a little bit about some of the differences between a typical serverless function and an edge function. I'm going to be referring to the case of Netlify, but this kind of applies as a general concept. At Netlify, when you write a Netlify function, a serverless function, you are always terminating a request. Let's say you open up a new project, you create a function file, we will automatically spin up a new URL for that function, and then you can hit that URL and we'll terminate the response with whatever logic you write in your function. You can also do that with edge functions. But there's an alternative mental model that you can use, which is you can make an edge function work like a middleware pattern. So you can make an edge function intercept a request as it comes in, or create an edge function that handles a response as it comes back out. And that suddenly creates the opportunity for some really interesting use cases, because you can have an edge function that sits right at the beginning of your request chain, and then your edge function can decide to terminate the request.

00:09:37 - Eduardo Bouças

That's also a perfectly valid use case. You can just return a JSON response with whatever, or you can modify the request in certain ways and then let the request continue its normal path through the request chain and end up in a static asset or a serverless function, for example. When you have access to that middleware pattern, you can do interesting things like A/B testing. For example, you can write a function that takes a request and then randomly assigns it to one of two buckets, and based on that, it'll route the request to a different path. You can do things like an authentication layer. You can write an edge function that runs on every path, and it'll do something like check for a JWT in a header or something. It'll validate that token and route the request to different places based on the permissions that are associated with that token, for example. I think those are a couple of interesting examples that are made possible by this middleware pattern. These two use cases are about intercepting the request as it comes in.

00:10:47 - Eduardo Bouças

And we can also talk about a couple of examples of modifying the response as it comes out. For example, you can write an edge function that will take the response that would normally be served for that path, and you can modify it. You can replace some of the text. You can, I don't know, replace the links that go to your Amazon store and make them go to your local Amazon store based on the geolocation for that request, for example. And I think that opens up a whole universe of use cases, because you have access to programming your CDN effectively at specific points in time. I think that can be an incredibly powerful thing to have in your toolbox as a developer.

00:11:32 - Christopher Burns

I've actually used edge functions before on our brand-new website at everfound. What we're using it for is detecting where the user is coming from, because what we're building now is a worldwide product that obviously has a SaaS plan for each country. So when a user goes on to it from, say, America, they don't want to see the pricing for the UK; they want to see the American pricing, and vice versa. So this is actually a really good use case for edge functions in something as simple as a marketing website. And you could be using it for pricing, or you could be slightly changing the illustrations depending on where they're from, to make them resonate more with the person who's viewing the website. And this is just scratching the surface, I believe, of this logic before rendering, and I think it's one of the most useful things that I could see being super successful on websites that are looking to grab a global audience while providing slightly tweaked experiences. I think they're definitely worth playing with, and I do totally think we've not seen the full usage unlocked yet.

00:12:34 - Eduardo Bouças

Absolutely. I think that's a great example. We do make geolocation information available to every edge function, so you can totally tap into that and make decisions based on the country, or even the city, and things like that. And I also completely agree with you. I think the examples, like we internally at Netlify, we have created a bunch of interesting examples of things that you could build with edge functions, but I think those are nothing compared to what the community will build. That's what we're super excited about, and that's why we're excited about creating something that is built on open standards, because you're not going to be building something that is specific to Netlify. You're going to be building something for the web that is going to help even us realize what the possible use cases are. And I'm super excited about that. I'm super excited to see what people build with that. One of the most exciting things for me is creating the tools and putting them in front of people, and then kind of seeing people who are way smarter than me figure out how to build amazing things with them.

00:13:39 - Eduardo Bouças

That's kind of the exciting part of my job.

00:13:41 - Christopher Burns

I can definitely see a few enterprise customers saying, this is perfectly what we need to navigate a user to a mobile version of the website.

00:13:51 - Eduardo Bouças

Oh no.

00:13:53 - Christopher Burns

I just quickly want to go back over to why Deno. Deno is this runtime, but why is it better than just V8? What is Deno versus V8, and why does it make a different choice?

00:14:07 - Eduardo Bouças

One of the things is performance. Deno was built with this specific use case in mind, if not from day one, then from very early on.

00:14:20 - Anthony Campolo

And just real quick, Deno does use V8, so Deno and Node both use V8, but they build stuff around V8. So it's not that Deno is not using V8 and Node is; it's that Node is a C++ wrapper around V8, and Deno is a Rust wrapper around V8.

00:14:39 - Eduardo Bouças

Yeah. Why we chose Deno as a runtime instead of Node comes down to performance and, exactly like you were saying, the choice to use Rust and to focus on performance. And this idea of building a runtime that could run in a distributed infrastructure like this, I think, is something that informed their roadmap. It felt like a really good match for what we were trying to build. And then there are choices in the Deno runtime that are not necessarily obvious choices, but are definitely interesting. The whole idea of not using a centralized package manager and pulling your dependencies via full URLs within your code, and again going back to the whole open-standards idea and this idea of trying to build on top of Lego pieces that are already available and that developers already use, that's also something that was really important to us. So I think that's why it made sense for us. It's a combination of all of those characteristics.

00:15:48 - Christopher Burns

How does Deno make working with, say, JavaScript different? Can I just build an Express API as easily in Deno as I can in TypeScript? Or is it completely different? Do I have to use a different package? And how does that reflect into edge functions? Can I build a REST API in an edge function?

00:16:06 - Eduardo Bouças

That's a great question. You mentioned TypeScript, so maybe that would be an interesting thing to call out, which is Deno has built-in first-class support for TypeScript.

00:16:17 - Anthony Campolo

Chris loves to hear that.

00:16:19 - Eduardo Bouças

If you want to write a TypeScript application, you don't need a build step. You don't need to transpile it or process your code in any way. There is first-class support in Deno. When it comes to building a REST API, absolutely. It's worth clarifying that if you have a Node project that relies on an npm package, that will likely not work on Deno out of the box, because those are different runtimes with different primitives. So relying on Express itself, or a similar package, probably won't work. But you can totally build a REST API using Deno, and you can build a REST API using Netlify Edge Functions. One thing that I would also like to call out is that, unlike serverless functions in Netlify that will automatically get a URL associated with each function, that doesn't happen with edge functions. You can actually go and configure a path, or multiple paths, that that function will run on. So, for example, we're talking about a REST API. If you wanted to create your API that handles products...

00:17:34 - Eduardo Bouças

Let's say you can configure a path like slash product slash star. And that means that that function will run on any subpath of products. And that in itself is a building block that makes it easy to build a REST API in a Netlify edge function. That was a long-winded way of saying yes, you can totally do that.

00:17:55 - Anthony Campolo

Yeah, there's also a Deno library called Oak, and so Oak would be kind of the equivalent of something like Express. It's technically based on Koa, hence the name, because Deno is Node with the letters mixed around, same with Oak and Koa. And I know that Oak does work on Deno Deploy, so I would assume it would work on Netlify functions as well. I'm not sure if that's something you've played around with, but actually that kind of leads me to another question. Is there kind of parity between what you can do with a Netlify edge function and what you can do with Deno Deploy, or is there some kind of secret sauce that Deno Deploy has that will allow them to do things that Netlify edge functions can't? Do you have any idea what the similarities or differences are between those two edge runtimes?

00:18:44 - Eduardo Bouças

So to your first question, yes, Oak is definitely an interesting framework to keep an eye on if you're in the Deno space. I haven't personally tried using it in a Netlify edge function. I'm pretty sure it would work. I don't see why not. So if you're building a RESTful API, that's definitely something you should look into. Your second question about the primitives that are available in edge functions and in Deno Deploy, I think there is parity. I don't think there's anything available in Deno Deploy that we don't support in edge functions.

00:19:16 - Anthony Campolo

That's really cool, because that would be what I would think of in terms of portability. And talking about having this universal runtime, if I could just lift and shift something from Deno Deploy to Netlify, that would be really powerful, because I think one of the reasons that Node really took off is that anywhere you could run a Linux server, you could really run a Node server. And with the edge, the problem has been that we're dealing with all these weird bespoke runtimes, like Cloudflare has their own runtime and Fastly has their own runtime and Layer0 has their own runtime. So getting to the point where we can actually lift and shift this stuff is what we want to get to with these runtimes. That's not really a question, but I would be curious to get into customers. Who is currently using this? Do you have any big flagship customers who are using this right now?

00:20:07 - Eduardo Bouças

The Edge Functions product is still in a public beta period. There's the whole sticker saying this is a beta product. You shouldn't rely on this for critical production projects right now. But we do see a lot of customers interested in or actively using it and kind of adapting it to their workflows. There are no specific customers that I can name that I can share. But we're super excited to see enterprise-level customers using this and helping us make it better as well, because learning from use cases, from a very small personal project all the way to a large enterprise site, is what we're interested in. And that's why we want to have this beta period, where we kind of learn about these use cases and improve the product.

00:21:00 - Anthony Campolo

Very cool. So I'd be curious how this currently integrates with the Netlify toolchain. I know Netlify has its own CLI, and they have a way to generate a Netlify function kind of boilerplate, which is the old-school Netlify Lambda kind of function. So is this something that also, now, if I wanted to spin up a quick edge function, would I be able to just run a command in the Netlify CLI and kind of auto-generate something?

00:21:29 - Eduardo Bouças

That's a great point. That's a great question. One of our main concerns was to take this technology and make it part of the Netlify workflow. That was the only way that we would want to launch something like this. And so, yes, in the same way that you can spin up the Netlify CLI and type netlify dev and you suddenly have your local development environment with access to your serverless functions, the exact same thing happens with edge functions. We use the Deno CLI under the hood, but we can abstract all of that. We take care of pulling it into your local machine. If you don't have it installed, we cache it for future invocations and things like that. We make the whole experience really seamless. An example that I wanted to share with you is if you use VS Code and you have a bunch of JavaScript or TypeScript files in that project that are associated with Netlify serverless functions, and then you suddenly add a new JavaScript or TypeScript file for an edge function, VS Code will not be able to figure out what is an edge function...

00:22:36 - Eduardo Bouças

What is a Deno TypeScript file and what is a Node TypeScript file. You might get some confusing warnings about some primitives not being available or things like that. And that's the kind of thing that we wanted to make seamless. So when you boot up the Netlify CLI and we detect that you're running it from VS Code, we go, well, you seem to be using VS Code and you're using edge functions. Do you want us to help configure your editor so that you can get an optimal experience from this? And we go and create a VS Code settings file that tells the editor where exactly the Node things are and where exactly the Deno things are, so that the whole thing works great for you. I'm going off on a bit of a tangent here, but my point is that, yes, edge functions fully integrate with the Netlify workflow. We want to make it as seamless as possible. To your specific question of can you type a command and generate an edge function, I don't think we've added that template just yet, but I will definitely create an issue right after this call, because that's definitely something we want to do.

00:23:42 - Eduardo Bouças

Absolutely.

00:23:43 - Anthony Campolo

Yeah. Generate a template string. It's probably a fairly small lift, all things considered. But that's interesting that you say it actually pulls in the Deno CLI. So would I need to have Cargo installed? That's kind of Rust's package manager. Or do I need Rust tooling, or is that kind of handled?

00:24:03 - Eduardo Bouças

No, that's handled automatically for you. We'll look at your machine, your OS, and your architecture, and we will pull the relevant binary and just run it for you. You don't even know that there is such a thing as a Deno CLI if you haven't used that before. Not because we're trying to hide anything away, but just because we want to make it as seamless as possible. And the thing that really excites me is making complicated things seem easy. We want to bring this technology to people without asking them to completely change the way that they build, or to completely change their workflows, or to ask them to suddenly learn this new thing and pull all of these tools from the internet and learn how to use them. We want to abstract away all of that complexity. So if you were using Netlify by just running Netlify Dev locally a month ago, you'll be able to do the exact same thing with edge functions without pulling any other tooling for that.

00:25:08 - Anthony Campolo

That's awesome, because I remember there was a time when I had to download the Wrangler CLI, which is Cloudflare's CLI. I remember it took me hours to figure out. It was just so complicated. So having that setup step figured out for you, it's so huge. And this is something that Redwood was always really good at. You don't need to download the Prisma CLI; Prisma is just in there already. So I think getting you set up in a way where it's like you install one tool, and then that tool figures out what all the other tools need to do to work, that is so powerful. And that's really, really cool.

00:25:47 - Eduardo Bouças

Yeah. I think we as developers often underestimate how difficult and how big of a task it is to have people installing all of this tooling and configuring all of these things to get to the exact setup that you want. And I agree with you. Having a tool that does it for you, obviously while having the flexibility to then go in and customize things if you have a really specific use case, or if you're a power user that wants to customize things in a certain way, you should absolutely have the flexibility to do that. You shouldn't feel like you're locked in to a specific configuration. But giving you reasonable, useful defaults that can get you up and running with no additional effort, I think that's key. And that's difficult to achieve from the engineering side of things. But as a user, I think people should expect that. And people should kind of demand that from the products that they use.

00:26:43 - Anthony Campolo

So if someone was going to get started with this, what is the hello world to edge functions? Where should people go in terms of getting set up, and what would they need to do to set themselves up for success?

00:26:57 - Eduardo Bouças

So I would go to the Netlify site, and there's a product page for edge functions that tells you what edge functions are. It has links to a ton of examples that show you how to build an edge function. And then to actually build one, it's pretty much as simple as creating a project, dropping a JavaScript or TypeScript file, depending on your favorite flavor, and saying what route that function should run on, and that's it. The API itself is very simple. It ties back to that whole idea of building on web standards, because the contract is we receive a request and we return a response. And by request and response, I mean the web standard Request and Response objects. That's the contract that you have. You have a file that exports a default function that receives a Request and returns a Response. And you were talking earlier about making it easier to just lift this code and run it somewhere else. That was one of the concerns that we had as we built this API, because on the one hand, we want to make certain things that are specific to Netlify available to your functions, like being able to use different parts of the Netlify ecosystem.

00:28:22 - Anthony Campolo

Yeah. So there's a thing with Netlify Graph on the home page for Netlify functions. It seems like there's some sort of integration there.

00:28:30 - Eduardo Bouças

That's an example of things that we will want to make available to functions. But we have this Netlify context object, which is passed to your functions, and all of the Netlify-specific stuff is in there. That's the namespace for the Netlify stuff. Everything else is the very simple contract of receiving a request and returning a response, and that's the standard stuff. If you take that and you move it somewhere else, that will work. And we want to keep it like that, because I think that's how we kind of move the ecosystem forward.

00:29:00 - Anthony Campolo

I am so excited for all of this stuff. As someone who has been really bullish on the edge in general and edge functions, and I've been doing a lot of work over the last year to try and figure out how to get Redwood to work with Cloudflare Workers, and now that we have more primitives for the edge and they seem to be more compatible with the deployment targets that Redwood already has, I think that we're getting closer to making this actually a real thing. And I know that there's someone on the Netlify team who is playing around with Redwood and Edge Functions. I won't put them on the spot, because I know that's still kind of in the process of getting done, but that's something that listeners should keep an eye out for, because I think that we're going to start seeing more integrations with frameworks. And if you go to the Netlify site right now, you already mentioned that this works with Next, Nuxt, Svelte, Remix. So it seems like there's already been a lot of work done in terms of making this compatible with popular meta-frameworks.

00:30:02 - Eduardo Bouças

Yeah, definitely. I'm super excited to see this working with Redwood. I'm not actively involved in the framework integrations, but I keep a close eye because I love seeing the innovation that's happening in that space, and I really like the mantra of Redwood. So I'm really looking forward to seeing it integrated with edge functions, and yeah, the rest of the frameworks and meta-frameworks that we have available. We launched with a bunch of adapters for those frameworks on day one, and we've recently published a document that gives framework authors the primitives that they need if they want to build an integration for their framework. And that's another area where we're super excited to see the community building their own integrations and their own adapters, and taking this technology further by offering super-easy integrations with different frameworks and tooling.

00:30:57 - Anthony Campolo

Do you have any other questions, Chris, before we start closing it out here.

00:31:01 - Christopher Burns

I do, but I feel like it could open the biggest can of worms in the world.

00:31:06 - Anthony Campolo

We got time. Go for it.

00:31:07 - Christopher Burns

We got time. Did serverless functions walk so edge functions could run?

00:31:15 - Eduardo Bouças

That's an interesting question. Just to make sure that we're on the same page, are you basically asking if edge functions will replace serverless functions?

00:31:24 - Christopher Burns

Yes, i.e., edge functions are faster, simpler, and better. So shouldn't we just all migrate to edge functions?

00:31:33 - Eduardo Bouças

That's a great question. This is my personal view on this. I don't see serverless functions being completely replaced by edge functions in the near future, for a couple of reasons. I think one of them is the runtime itself. I'm a fan of Deno, but the Node ecosystem is quite big, and it has a large community. It has a large library of open-source packages that are built for that runtime. There are a lot of people that will continue to depend on that ecosystem to build their applications, and I don't think everyone will immediately migrate to Deno. Another aspect of that is: should every application be built on the edge? And that's a really interesting question that, as you say, we could open a big can of worms here. I'm not sure if the answer is yes. If you're talking to a database that is in a centralized location, for example, or lives in us-east-1 or something, will you get the full benefit of the edge architecture if your functions are still going back to that centralized location?

00:32:45 - Eduardo Bouças

I don't know. There's a ton of innovation happening in this space right now. I think the database world is super hot right now, and I think we'll see a lot of innovation in that space. And there are a lot of players that are moving the databases to the edge. I think that will be a really interesting conversation once we get there. Right now, I think there are still some questions to be answered there. My best answer to that is not right away, but possibly in the future. Exactly when that future will come remains to be seen.

00:33:16 - Christopher Burns

I played around with serverless functions in the early days, with very much the alpha of the Serverless Framework. I remember looking on Amazon's dashboard and being like, "Serverless, Lambda@Edge," and being like, "What the hell was that?" I didn't even know how you even got close to using that, because AWS is so complex and everything. And then serverless functions didn't work right for me. They just didn't click. Having a server plus a database in one location, where they're both literally right next to each other, I think, is very much a thing in my eyes. Could we see edge functions being the new norm? Only if every other part of the jigsaw matches it. If edge functions are the norm because your files are hosted on a CDN that's on the edge, your functions are on a CDN on the edge, and also now your database is on a CDN on the edge, I think once we hit all three of them and they're super tightly coupled, to the point that you don't even need to think about running it on the edge, it's just the norm.

00:34:13 - Christopher Burns

As in, you never even have to think about what location your code is in ever again, because you're expecting it to be everywhere. When you talked about the future of whether it will happen, that's when I think it will happen.

00:34:26 - Eduardo Bouças

I completely agree. I think we're still in this phase where we have the technology to run things at the edge. We don't yet have all of the things that we'll eventually want to run on the edge. And once we get there, like you say, I think it may change the landscape. And maybe at that point, yes, maybe at that point it will not make sense to run a typical centralized or regional serverless function.

00:34:49 - Anthony Campolo

Thanks so much, Eduardo. This has been an awesome conversation. Thanks again to Jason for connecting us. Why don't you go ahead and let our listeners know where they can get in touch with you, where they can find you on the internet. And then I think we already kind of gave a good idea of where to go for Netlify Edge Functions specifically.

00:35:08 - Eduardo Bouças

Yeah. So you can find me on Twitter at @eduardoboucas, and my website is that as well. My DMs are open. I'd love to chat about anything Netlify or edge functions, or web development for that matter. So yeah, I'm excited to speak with folks about this. And yeah, thank you so much for having me. It was great chatting with you.

00:35:30 - Christopher Burns

Thank you. I'm sure we'll speak again in the future when there's a more exciting feature to happen. I'm sure it will happen.

00:35:38 - Eduardo Bouças

Absolutely.

00:35:39 - Anthony Campolo

Yeah. Netlify never runs out of fun new toys to play with.

00:36:14 - Anthony Campolo

All right.