>> Scott Moss: All right, and that kinda brings us into the next thing
that's very much more of what I was just saying, and
that is going to be the edge compute stuff.
So I talked a little bit about it, but I was trying not to talk about it cuz I
knew I was gonna talk about it now, but now I'm talking about it.
So what is Edge Runtime?
It's basically a very lightweight JavaScript environment.
I have provided by Vercel here, but Vercel didn't create Edge Runtime.
[LAUGH] They're not the makers of Edge Runtime.
It's just a slimmed down version of JavaScript,
it's actually more similar to the web than it is Node in my opinion.
So far you've known browser JavaScript with Windows and
then you've known Node JavaScript with modules.
Now there's Edge JavaScript, there's a third one now.
[LAUGH] And it's way different and it's way less and it's more strict, right?
This is the first runtime that is limited on the actual things you can use,
how big it can be, how the size, all different types of stuff.
And the reason that is the case is because if you're running something on the Edge,
the window in which you have to run that is really small.
So it has to be lightweight, it has to be quick.
So there's a lot of limitations on things you can bring in,
you can't load up 500 megabyte app on the Edge at that point.
Any benefit you would have had of running that computation on a server closest
to your users is now null because it took so long to load that file.
So what was the point?
You should have just went to your origin, you should have just used Redis or
something like that.
So anyway, it's meant to be lightweight,
it's fast, minimum code starts.
It's basically optimizer functions, I need to get things done quickly,
closer to the user, we did authentication, personalization,
A/B testing is a huge one or just like other request-time ops.
Here's just a little chart that I put together that shows some of
the differences.
So you can see the big one is a Node.js runtime,
you can have functions that are several gigabytes in size.
You'll pay the price, but you can do it.
This usually lower than that.
Execution time, most of them have very strict execution times on how you
can do Edge function, and if you go past the execution time, it'll just stop.
And I'm talking like three seconds,
two seconds, something like that.
Yeah, so lots of stuff there, how do we do Edge Runtime in Next.js?
Well, we just did one with the middleware for free, that's always an edge.
On our local computer, it's just node and that can be confusing.
You might pull in some code locally during dev time,
when you're running on your computer and pull in something that works in node.
And you run it in here and you're like, wow, that worked.
And then you go deploy it and it doesn't work because the thing that you imported
was in node and this executed in node on your computer.
So it worked on your computer, but when you deployed it, it doesn't work.
So that's something I see happen a lot.
The other way we can do Edge is, yeah, I was right.
You can export const runtime edge inside of API route or
a server component and that will tell Vercel,
hey, use the Edge Runtime for this function.
Now that doesn't mean it's gonna work,
it just means that that's the runtime it's going to put it in.
You still have to do your job to make sure
that you aren't using some of the node specific.
What if I put some of that stuff in here?
Node specific modules that don't work in Edge and I mean,
you're gonna get an error, so you don't really have to think about it.
It's gonna work or it's not gonna work, but there are websites dedicated to
showing you, does this work in Edge, and things like that.
I would say for the most part,
most technologies coming out now try to maintain to be Edge compatible.
So that's something you got to look out for,
now if you're ever gonna use something.
There are different approaches to how to get Edge to work, there's shimming,
poly filling things like, maybe file system doesn't work on the Edge.
But instead of forcing you to go delete all your file system code,
we'll just mock it all out.
So it doesn't do anything, but it won't break.
So there's different attempts.
Vercel has their own attempt where they want you to get Edge computing but
also still keep all your node code, and it's pretty ambitious.
And so far it works pretty good but that's a whole other thing.
Yeah, here we go, I was like, I know I put this in here somewhere.
So here's some things you can do in the Edge,
you got fetch that works for request and response.
You got headers, text, encoder, crypto, the stuff that you would probably use.
You might not use a lot of this stuff directly, but
a lot of the things you use, use this.
So it's pretty good to have this.
And then Next.js provides these helpers for you.
But again there are some limitations, for instance, file system,
memory constraints, execution times, different things like that.
>> Speaker 2: What's that geolocation stuff?
>> Scott Moss: The geolocation, this one right here.
So this one right here, the geo-property that Next.js puts on the request,
it just tells you more about information of where the IP address came from.
So I think you might have to buy into some of that, don't quote me on that.
But I think there's some additional stuff you have to do there, but
it could give you the longitude, latitude.
But more specifically I think it gives you the region of where somebody's coming
from, maybe the locale, the language, things like that.
Stuff that's already on the request object, they just format it nice for
you, and they might do a thin pass through of it.
>> Speaker 3: Is the Edge Runtime like standard across providers or
is a vendor locking to Vercel or?
>> Scott Moss: It's standard across providers.
Just like node is standard across providers and I guess,
the browser runtime has different JavaScript engines, but
still that's also standard across browsers as well.
So nobody owns it, it's a spec-specific runtime, yeah, great, I've been
talking about you also need storage on the Edge if you're gonna use Edge compute.
Well, Vercel has something called Edge config which is simply just a key
value store, you can think of it as Redis on the Edge.
The way you get around a lot of stuff, just make sure it's HTTP based.
If you can interact with something over HTTP,
you most likely will be able to use it on the Edge,
if the mechanism in which it's doing HTTP is fetch or response or request.
You won't be able to use something like Axios on the Edge,
that's just not gonna work.
It's not gonna work.
So HTTP uses web standards, it'll work on the Edge, and to me,
that's what serverless means, that's what edge means.