Hey everyone today I'm joined by Kelsey Hightower
he's a developer, author, father, and minimalist. You might know him from the Kubernetes community
or his work as a principal engineer at Google. Thanks for joining me today. Kelsey: Happy to be here.
Lee: I'm really excited to dive into edge functions and I know that you like to explain things based on
the fundamentals so I'm really excited to take a step back look at those principles and talk about
how they're changing how we build for the web Kelsey: Yeah so you know for those watching you know
my background as a back-end engineer I come from a world where you have a three-tier web app
you know front-end back-end and a database and maybe a load balancer in between so getting the
taste of all this serverless edge functions and how the web front end is evolving is super
interesting to me so I'm looking forward to breaking down those fundamentals. Lee: Awesome, well
to kick things off I would love to just talk conceptually about why the edge why
are we moving more compute to the edge I'd love to hear your take first and then I'll
kind of give my opinion on why we're moving more logic to the edge. Kelsey: Yeah so you know the space that
I come from you know containers or even serverless you know in the cloud we tend to think about
regions and zones so ideally you get as close to the customer as you can but typically you're
still running out of a centralized data center and for the most part this works just fine for
a lot of people but when you think about use cases like gaming for example you really want that
client wherever the customer is to be connecting super quick uh to the edge also in my world the
you know the explosion of CDNs as you think about the Netflix use case or you're serving images
you want those to be as close as the customer as well so they can render fast load and you're
not pulling data across continents so I think that's been our first taste so for many people why
edge and it's like why edge for specific things some people are still comfortable with
centralizing some of the logic maybe your order management system or your company or
customer profiles I think a lot of that is still largely centralized even though we've moved
the closer to people at the continent level but I think there's always been a case at least
in the last 15/20 years of moving static assets like videos and images to a CDN which tends to
have way more locations than our standard regions Lee: I love the two points you made about one
just trying to get content closer to users but then also effectively using the right
tool for the job it's not that we're moving every single workload to the edge it's another
tool in our tool belt that's enabling us to build better applications for the web I think when I
look at why edge and just the landscape of web development in 2021 it seems like what appeared to
be static for a lot of sites is actually kind of deceptively dynamic because the requirements
for personalization and experimentation kind of put us in this tough spot as developers where if
you wanted to have dynamic you might have to you know especially with a global audience you might
end up with a slow application and if you try to solve that like solve the speed problem by making
it static well now you lost the personalization or the dynamicism so it's been difficult to get
both so where I view edge is kind of trying to solve both of those problems together dynamic
at the speed of static and I think historically you know your context about CDNs when we went to
the edge with edge networks or CDNs we lost a lot of the abstractions that people coming from the
server world like you know like express middleware right we lost some of the control and flexibility
there so we're trying to bring that back with edge functions and we're doing it through an
abstraction called middleware so it essentially allows you to run code before a request is
processed and then based on that request you can modify the response with rewrites or redirects
or headers all that stuff trying to enable code over configuration and get closer access to that
infra (infrastructure) at the edge like running as much compute at the edge as we can for specific use cases like you
mentioned yeah. Kelsey: So the good news is I got to put my hands on it and so you know the limited front-end
experience that I have comes back from like the PHP days right you would render as much as you
could on the server side and then you would send over you know a bunch of other things that then
may do a little bit you know the jQuery days where you can kind of context switch based on limited
information you had from the browser or maybe the user session and so I looked at how some of
these frameworks evolved over time and I've always had these questions like where do you put things
like secrets or database connections and it seemed like the industry had evolved to the point where
you could have maybe individual components like the calendar widget or the stock ticker widget
but they always seem to talk all the way back to the back end right so you got as close to the
customer on the front end but then there would be parts of it that will still have to travel over
long latency stretches to work and I think what we tried to do then solve the problem of async
right they just kind of load at their own pace maybe you're getting some of that data from a
cache if it's not really personalized for a user and then I touch the kind of new stuff that you
all are uh talking about with some of these edge functions and so I the first experience that I had
there was like this feels more like Ruby on Rails so Ruby on Rails is this really powerful kind
of convention over configuration framework where you could just you know design your app in a
certain way lay out certain you know folders and structures and then when you built the app it did
all the right things in terms of rendering kind of this back-end applications with the best practices
I think you all are trying to do that for front end and addressing some of these going all the
way back to the central server by having parts of the application run in this new serverless edge
computing platform where I kind of get both the best of both worlds without necessarily thinking
about how I deploy each and wire them back up Lee: Yeah I think what I 100% agree with that and I
feel like it ties into this evolution of the traditional way we were building web applications
and how we're trying to help bring developers on that journey to the future and bring them along
with us as we enable and give these primitives to try to make it easier so I would love to dive
into this topic a little bit deeper because I really appreciate your experience and your context
on some of this I'll try to give my perspective as a front-end engineer and as somebody who you know
doesn't have as much experience in the infra side and I'm curious to see how it kind of compares
against yours because I know that you've you know you've spent time as a system administrator
you've been an advocate for Kubernetes and because of that you know you've moved along from manually
configuring VMs moving up the stack to Kubernetes and I feel like when I've listened to you talk
before about this you try to root yourself in like different the first principles of web development
right like it's important to understand we're fundamentally just writing software and it's going
to run on a system somewhere and the closer that system is to your users ideally the better and
we touched on this a little bit before we we started but you know ideally you could have that
system be the browser right that's as close as you could possibly get to the users but it's not
really practical to run all of your compute there so in the front end world from my perspective
React has essentially become like Linux it's this open standard for building the web and
then you have Next.js which is the most popular distro of using react so an analogy I like for the
backend folks is like when you're using Kubernetes you might be using tools like Helm charts as
an abstraction to define your infrastructure so this is you know for those not familiar
it's like infrastructure as code and then you can develop and maintain your infra the same way
that you would your code but at the end of the day those tools are just compiling down to like
YAML right they're just making it easier or an abstraction layer on top. Edge functions
in my opinion are very similar they allow front-end developers, back-end developers to write
javascript that ultimately just compiles down to some serverless compute that's running at the edge
it's I like to think of it as like infrastructure defined from code so a little different than
that traditional model what do you think Kelsey: Yeah, so I think when I think about context is you
know if you think about the base principles of it there's a database your system of record it has
all the products and the prices of those products and your goal is to try to render a shopping
experience to people that are using a web browser. So in that world my server is going to say hey
you hit this URL I'm going to present to you a page with my entire catalog in it and then you
can browse around in that experience I think the challenge is I need to render your shopping cart
uniquely to you so I'm going to have to go back to the server and tell the database what you
bought to make sure that my database and what you see in your browser are in sync and I think
that's been the traditional model that we went about doing this yeah and so you're right in the
Kubernetes world that back-end application I did a lot of work to give it a configuration file with
the database username and password so only that back-end application could connect to the database.
On the front end there's a lot of work that goes into identifying who you are and then having your
browser session pass back those credentials to my back-end so I know that I can look up data in
my database and take actions on your behalf I think now what we're talking about is moving
some of this logic even closer to the edge and now you get into some real tricky situations where I
can't give you my database password in the browser this would be a nightmare and you could actually
do anything on behalf of any user so we know we can't go that far with things like database
connections right so we gotta move that one layer outside of the browser now typically that
would be something like even a serverless platform like Lambda or Google cloud functions that's one
layer and then at that point you're just giving connection details uh to some API on behalf of
that user that all makes sense to me but I think now what we're saying is do we really need to go
all the way back to even a serverless function or a container running in Kubernetes could things
like how we process headers like if you're coming from australia and I might want to show you
a different set of content well I can make that decision now in the edge aka where the CDN
traditionally sits I think that's where it's going to get super interesting and now I think as people
coming from the front end or from the back end we now have a decision to make where do we put this
kind of logic and where does it make more sense Lee: So I'd love to pause here and to
actually look at some code that kind of explains what you're talking about how can we
push authentication or logic closer to users a layer back from the browser and make that have
lower latency in their request so let me share my screen and I'll pull up some code so I know that
you've had a chance to check out edge functions ahead of time and one of the ones that I think
is really interesting is using JWT authentication so in this example I have this edge
function that's deployed and it's checking this JWT token and essentially there's
two different API routes we have one that is just a normal API route and then we have another
one that's actually using an edge function so to try to demonstrate this what I've done is have
two different APIs shown below one that's using edge and one that's using just going to origin
now this isn't perfectly realistic because it's not actually doing the full authentication with
some provider but I think it helps to at least illustrate some of this so ideally you're going
to see the edge responses be a little bit faster and I'd love to take a look at some of this code
and kind of talk through what that looks like so on the left inside of this example we have our
pages folder and the convention that we're using to define how you invoke this logic is called
middleware so inside of our API folder we have a new file underscore middleware and inside of
here we're taking a look at the url if it has the parameter of edge then we can essentially
directly respond and handle that authentication without having to do that extra check towards the
API route so then this logic actually runs before the API route logic now this logic it effectively
does a very similar thing it looks at a cookie it verifies a token and then it returns some
payload based on that but the interesting part is when this actually gets deployed on a platform
like Vercel this could get deployed as a function somewhere and this can get deployed as an edge
function so the difference kind of between a serverless and an edge function here is the edge
function is another layer closer to your users Kelsey: Yeah and so this makes a lot of sense to me
because when I look at this traditionally when we try to do this type of logic we used to
use things like Nginx or Apache we would go find some module and you go to the centralized system
and as a developer you would have to know how to edit a Apache config maybe even restart that
server and wire everything up to do this kind of logic right so I want to add authentication to
this app now I got to go hunting for one of these systems that I should go do it at I think now what
we're getting and if I understand this correctly as a developer I can stay within my same
application logic and then just add this middleware not deployed to a backend server not
touch Apache but just stay in the same flow that I'm already in and just say look I have this logic
we'll never go to the browser I think that's kind of the key point here it's going to instead get
deployed somewhere where Vercel's platform is going to wire it up automagically intercept the
traffic and then do all the logic that's in here and then I just hit save redeploy my app and
now I have this thing that just sits in the middle without thinking about touching five
or six different places and restarting things I think that is probably the thing that might
blow people's minds in terms of you have this self-deploying thing that knows automatically from
convention that it needs to get deployed one layer below the browser and just available everywhere.
Lee: Yeah and I think building off of this too it's it's enabling a new set of of developers to take
advantage of some of these tools that maybe they had deferred to another part of the team or you
know they thought was outside of the scope of what they could do and another interesting example
of this I can show is let's say you have some API and you want to do some kind of rate
limiting with it let me pull this up here Kelsey: And as you're showing this the thing that
comes to mind though maybe I don't know how we answer this question but you know typically
one benefit of the centralized world is that I can define these things like
rate limits you know in one place and then all applications can just
point to my centralized kind of middle you know proxy Nginx or Apache and I can
just handle everything there. What challenges does this present if every developer in every
application is kind of embedding this logic and I need to go make a global update to all the
components what's the tradeoff being made here Lee: Yeah that's really important to talk about because
I think we've seen developers want to move closer to the edge and because their edge compute and
logic was decoupled from where they were actually deploying their application there were two
completely separate workflows and pipelines and because of that you could often get into instances
where your systems got out of sync essentially and you know even on a fundamental level of
caching now you have two caches in the mix so the closer that we can marry the infrastructure
to the code that we're trying to write and define helps developers fall into that success pattern
where they can use these primitives and not you know shoot themselves in the foot essentially
by putting in logic that is going to ultimately end up in a bad experience. Kelsey: Is there a way to
share some of this logic let's say developer A writes a perfect you know geo redirect function
and in my mind coming from my world I would like to write that once put it somewhere and give it
an endpoint and then have people just call that as like another API component is there an opportunity
to do things like reuse logic versus it seems like maybe embedding it in every app that I'm working on.
Lee: Yeah I think that's a fundamental part of what we want to achieve with edge functions and through
the abstraction of middleware is empowering developers to bring back some of that flexibility
that folks are used to with things like express middleware so whether I'm doing an authentication
check whether I have this library here for IP blocking in this example all these things that are
going to start to be pretty common use cases for middleware I want to abstract those out into a
reusable package and use them across different projects or make them open source and the nature
of you know bringing middleware to open source and Next.js and other frontend frameworks is that
they'll be able to npm install these packages and integrate them into their existing systems so the
constraint here and part of the reason why edge functions are fast is the underlying run time that
we're making so we're making a trade-off by not exposing the entirety of node.js APIs and instead
constraining the runtime to use standard web APIs like fetch or crypto and being built on top of the
JavaScript V8 engine because of that we're able to eliminate some of the remaining trade-offs that
you had with serverless so the cold boot problem connection pooling and more easily deploy these
functions globally so if I want to extract this logic for blocking IPs I can put it in
an ES module that's not using you know any specific node APIs and then easily
install that and share it across my team Kelsey: Alright now this starts to make a lot more
sense because now that I'm looking at it this is how we do and think about network
configurations right there is like a module that does things like IP blocking and then it's on
the developer or the operations team to configure what IPs they would like to have blocked and
for what reason and so it seems like if I were to centralize this into a high level library
then I could easily just say hey what you're really doing with this middleware is deciding how
it's being used like configuration if you will and then that module and that code
can be reused so my guess would be if I want to centralize that I would just treat
it like any other software package version it and then if we want to roll it out everywhere someone
would just do a redeployment and you would pick up all those changes and it will be pushed out across
the entire edge. Lee: 100% yeah and to take that even further too like there's so much of this logic
that we could be abstracting out to share like to further hammer home that point about IP blocking
over here you know I can essentially enable these developers to put in any IP address they want and
you know add it to a global configuration of some some list of blocked IPs whether that's manual
or automatic so maybe you want to manually do this configuration or maybe in this example
on the left you want to set up a middleware to have an API that automatically rate limits with
exceptions around you know bearer tokens or some kind of auth token and if they have that token
then we want to up those rate limits quite a bit because we know that they're a trusted party of
using this and that essentially comes down to a few lines of code assuming that this
right now while it's in this repo you could really easily abstract this out into a library and then
it's just a weight rate limit and that's the only code that you need. Kelsey: So one question I have from
this because this is genius so this looks like what we used to do with things like Lua modules
in Nginx but again we would have to do it for every round it could get super messy and also was
so disconnected from the actual application the one question that kind of stands out for me here
is where do you put the config for example if I do have like 35 IPs that I want to store to check
against I don't see a config file here would I actually have to establish some other data source
like a database or I think you're using Upstash which is like I believe a Redis compatible API
that's hosted somewhere else. Lee: Yeah the great thing about Upstash here is we're using it as a rest API
for Redis and it's globally distributed deployed across the world but you bring up a really good
point which is we've given you this abstraction we've given you the tool but what about the
data layer how are we going to solve that piece so right now from a Vercel perspective the edge
functions on our platform currently don't have an integrated key/value storage solution but that's
something that we're actively looking to support to eliminate the need for a developer to go
outside of the platform to do to find a place to store that configuration now over time we might
see that evolve even further but I think key/value is really the first concept for us to nail that is
very compatible with use cases for edge functions Kelsey: Alright now this makes a lot of sense because
now I think you kind of solve the you know the configuration problem you know as I make changes
than decisions either in real time or dynamic then I now have a place to kind of store the
actual output of some of those decisions and also some of the things like caching layers
if I've already made a decision the last thing I want to do is recalculate
the decision in a small window of time I guess for me it's like what doesn't go into
this layer right to really understand something I always think it's important to know when not
to use it should people be thinking about taking their entire like product catalog and stuffing
that into a CDN or edge or something like upstash Lee: Yeah that's a great question it
kind of comes down to where we see the future of web architecture headed so specifically
if we look at databases I think we're seeing this new breed of databases that are edge first
so we talked about key value stores but it could be a SQL like schema or evolving databases that we
already know like Postgres or MySQL to run global first and I think when you ask what doesn't
work we're seeing that a lot of these applications are getting modeled after eventual consistency so
with e-commerce they might be favoring speed over global consistency and in my opinion we're kind
of going all in on that model allowing people to essentially granularly cache things at the edge
now what those things are it might be compute or it might be actual React components so we can
dive into this a little bit later but it's it's still then allowing you to pick back up on the
client side and have the full power of JavaScript so I think that when you look across different
industries e-commerce but even in like finance or other sectors, databases are kind of going global
and combining that with the edge is just trying to make it fast everywhere does that mean that we
need to move everything to the edge I would say no especially if you're trying to do something
that has you know a hard requirement for global consistency in my opinion the eventual consistency
model just maps better for this type of logic Kelsey: I also think we're thinking about better access
to those type of systems whether it's centralized or distributed across an edge that comes
I guess as an implementation detail if I have the ability to reach these type of systems
from like this new kind of function framework then does it matter where it lives right I could
sign up for a hosted service and all I'm concerned with is latency to my data and they can achieve
that by putting my data replicating it very close and so be it so I think maybe that's where
we're headed it's just the distributed landscape similar protocols and we're cutting down things
like latency and some of those challenges by bringing things closer to the compute
Lee: Yeah the way I like to look at it is I think that hopefully it's a natural transition up
the stack for backend developers who are trying to learn more about serverless or edge
because in making the constraint about the you know the limited run time and not being
able to use node APIs inside of an edge function I feel like in getting rid of some of
those trade-offs that they might have previously correlated with serverless and trying
to make it fast by default I think will help them adopt and understand the use cases for a lot of
a lot of the applications of edge functions or middleware and then to your point about like where
this will grow so right now with the you know the Vercel platform enabling edge functions we're
already seeing I think a rise of this type of edge compute across the industry and my expectation is
just to see this continually rising not only for compute at the edge which has been around for you
know a few years now and rising popularity but also running your actual application rendering at
the edge so the way I like to think about this is a lot of that sounds kind of like 2000's web like
you just serve a render and you get your page and there was this transition from let's do everything
on the server to let's do everything on the client and some people fought back about that not
everyone thought that was the best approach and now I think we're kind of converging
and coming to this happy medium where we say you know actually those those server people were
right and those client-side developers well they were they were also right about some things too
we want to take the benefits of the 2000s web of fast single page or fast server rendered
applications and marry that with some of the inventions that single page apps or client-side
apps gave us with fast navigations through pre-fetching of routes you click on a link
and it feels instant it feels like an app so what I see the edge doing for the future of
cloud computing the future of the web especially with innovations like React server components is
bringing back the server first model and getting quick responses directly from the edge while still
remembering the innovations that we made on the client side for interactivity to then hydrate or
add more logic after your page loads and I think Kelsey: You know one thing I can think of here is that
the networks have gotten so fast whether we've just made them bigger and closer to where things
are happening that we're almost now at the point where we can treat you know there's the same
we can treat the data center like a computer but now with these networks so advanced you can
almost treat the internet like a computer itself and so now the operating system and now you know
through this conversation Vercel just feels more like this operating system for this kind of
distributed computer that says hey just like on a single server you know that some things will get
loaded into memory and some things will be saved to disk some things run in kernel space some things
run in user space and sometimes we create these boundaries for security reasons sometimes things
just don't make sense to run in one place over the other and I think computing we've always had
this trade-off between security and speed and you put things in the right place but I think now what
you're doing is trying to blur those lines to say we just treat the whole internet as a computer
and we'll just allocate things where they need to be in order to satisfy those two concerns I did
learn a lot just from having this conversation so I think other people that are watching if
they you know watch the whole thing asking these kind of questions back and forth like why
are we here now what does it bring to the table and even having that code walk through I think
was really helpful for people to mentally map what things are happening but yeah I think Vercel
is an as an operating system for the internet I think it just makes it easier to grasp
what's happening you got to just let go you got to let this thing figure out where
things need to be deployed wire them back up and own how it works and that's what kernels do on
operating systems
Lee: Yeah I think I think developers thought it would be easier to decouple their
application from the infrastructure and I think where we're moving it's like but there's actually
a lot of trade-offs with that there's there's a trade-off with the flexibility of moving your
application but there's also a lot of value in the closer you can marry those two together and the
great thing about Next.js in my opinion is that when you deploy next guest to Vercel you're making
the trade-off to marry those two together but its core is still open source so if you decide I'm
done with Vercel I don't want to pay them any more money and you say I'm gonna go host Next.js on GCP (Google cloud platform)
you totally can because all of these primitives that we're introducing like like middleware
it would just run on a single origin server so I really like that because it's still
bringing value to the entire ecosystem and eventually to other frameworks too the way
we've designed this abstraction on Vercel is that it will work automatically with Nuxt or Svelte or
any of these other languages or frameworks just by conforming to our API for how you implement this
Kelsey: Oh that's dope that's going to be good to call out on the docs and when you give people the
experience because some people I think that is kind of the question we hear when we think about
these new platforms they feel like black boxes and it reminds people of kind of like lock in
but it sounds like that's going to be addressed up front in this design
Lee: Yeah and the way I like to think about it is we're moving to this world where if we truly do build the
SDK for the web people will still have their syntactic sugar and preference of choice and
there's no way to get around that and that's okay we should be empowering those developers to make
innovations in their own spaces but we still want to give the same shared legos and building blocks
for creating a great web experience so when I look at the Vercel platform we're investing heavily
in what we're calling the file system API which is conform to this file system output dump it on
our operating system and it will just run globally and use all the features that are possible
and it's so easy then for framework developers I could go out and build my own framework today
and it could have web vitals analytics, image optimizations, edge functions, serverless functions,
CDN caching just by conforming to some output Kelsey: No it makes sense I think now that we you know the
web may have finally found its operating system Lee: I love that tagline I think we're going to steal
that and on our home page it's going to say Vercel the operating system for the web
cosigned by Kelsey Hightower
Kelsey: There you go Lee: Well thank you so much for
taking the time to chat today I really appreciate it and for those watching I
hope you enjoy the rest of Next.js conf too there'll be lots more content around edge
functions.
Kelsey: Thanks for having me
Lee: Thank you
