Edge computing is becoming a popular way to deliver modern web applications. Let’s find out if the Edge is really faster by comparing Firebase to Vercel Edge Functions with Next.js. 

#webdevelopment #javascript #vs  

🔗 Resources

Next Firebase Course https://fireship.io/courses/react-next-firebase/
Next.js 12.2 Release https://nextjs.org/blog/next-12-2
Cloud Flare Workers Docs https://developers.cloudflare.com/workers/
CDN Testing Tools https://tools.keycdn.com/performance

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- What is edge computing?
- Edge computing benchmarks 
- Next.js Edge Functions Tutorial
- Are firebase cloud functions slow?
- Edge Computing drawbacks
- SSR Edge Rendering 
- How to prevent cold starts on serverless functions
2024-02-04T13:35:20.064Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
764e640c-cb21-42d2-a9a8-551f52d6f667
954458554137c6295feb9fa47f84aa00db5df14cc6cf7646dadb19f52abea965
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
If all your friends jumped off the edge of a cliff, would you do it too?
In today's video, we'll find out.
All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions.
And just a few days ago, Next.
Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes.
Sounds edgy, but what does that even mean?
Is it some magic new way to make web apps faster or just marketing nonsense you can ignore.
Coca Cola with a new taste, a new explosion of wonderfulness in your mouth.
I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking.
But first, what even is edge computing?
Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4.
Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server.
The problem is that your users are all around the world.
The speed of light is fast, but not instant.
So being physically closer is faster in theory.
Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world.
That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world.
That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in.
Edge computing changes that.
It's like a CDN for a full blown server.
That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world.
As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users.
Sounds awesome, but what's the catch?
Well, in order for the system to scale, there needs to be a very minimal runtime.
That means Node.
Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box.
You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte.
That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge.
What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages.
All you have to do is export a configuration object from that route.
It's nice to have that flexibility because what I'm about to say next might shock you.
Edge computing is not always faster.
In fact, it can be significantly lower in certain situations.
Allow me to demonstrate.
In this project, I have a Next JS app along with a Firebase Cloud Functions back end.
I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP.
The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next.
Js code runs on Vercel's Edge network.
In this first experiment, I have a function that simply returns a JSON response with the text of hello world.
One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available.
The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively.
From there, I opened up Insomnia to test out both endpoints from my location in the United States.
The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast.
However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps.
The cool thing about Vercel Edge functions is that there's no cold start.
And not only that, but I'm getting consistently higher response times that I am on Firebase.
The problem though is that testing from my own computer isn't a very good benchmark.
What we need to do is test from servers all around the world.
Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this.
It makes requests from different locations around the world and measures the speed of the response time.
What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server.
After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia.
Why is that?
Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa.
Dallas got the fastest response time because it's only 500 miles away.
New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away.
Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there.
Good luck explaining that one, globetards.
Fatality.
Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world.
Like Sydney was actually twice as fast as Dallas.
Bangalore once again has a high response time, but that's mostly due to a long DNS lookup.
So the edge is clearly faster overall, but but here's where things get interesting.
What if your edge function needs to query data from a database or API?
Imagine you have an edge function in New Zealand, but your database lives in New York City.
In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand.
The end result is a much longer round trip.
You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand.
To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response.
In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request.
Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function.
Council Bluffs, Iowa.
Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio.
When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world.
The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow.
Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function.
Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped.
The bottom line is that the edge is much slower when remote data fetching is involved.
The only way to avoid that is to also distribute our database around the world.
There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis.
The cool thing about Next.
Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes.
It's not an all or nothing decision which really allows you to fine tune performance.
Now, the other thing to keep in mind here is that you can also cache responses from functions.
That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests.
Let's go ahead and benchmark that as well.
In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes.
When a new request comes in, it will send a response like normal and then cache it on the edge.
That cached value will stay valid for 5 minutes before a new response is generated.
That's important because it means it won't do that full round trip to the database if a cached version is already available.
Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well.
To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly.
That can be accomplished by rewriting a route and hosting to a cloud function.
Then in the function code, I'm also setting a cache control header just like I did in the Vercel function.
And now we can run our benchmark again.
What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds.
At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast.
But at this point, they're both so fast that the end user would never notice.
I think the only way to properly describe it is blazingly them really fast.
The one issue with Firebase functions though is that you still have the cold start.
However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month.
And that's what it's like to live life on the edge.
Living on the edge.
If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO.
Thanks for watching, and I will see you in the next one.

Speaker 0: If all your friends jumped off the edge of a cliff, would you do it too? In today's video, we'll find out. All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions. And just a few days ago, Next. Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes.

Sounds edgy, but what does that even mean? Is it some magic new way to make web apps faster or just marketing nonsense you can ignore. Coca Cola with a new taste, a new explosion of wonderfulness in your mouth. I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking. But first, what even is edge computing?

Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4. Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server. The problem is that your users are all around the world. The speed of light is fast, but not instant. So being physically closer is faster in theory.

Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world. That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world. That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in. Edge computing changes that. It's like a CDN for a full blown server.

That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world. As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users. Sounds awesome, but what's the catch? Well, in order for the system to scale, there needs to be a very minimal runtime. That means Node.

Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box. You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte. That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge. What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages. All you have to do is export a configuration object from that route.

It's nice to have that flexibility because what I'm about to say next might shock you. Edge computing is not always faster. In fact, it can be significantly lower in certain situations. Allow me to demonstrate. In this project, I have a Next JS app along with a Firebase Cloud Functions back end.

I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP. The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next. Js code runs on Vercel's Edge network. In this first experiment, I have a function that simply returns a JSON response with the text of hello world. One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available.

The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively. From there, I opened up Insomnia to test out both endpoints from my location in the United States. The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast. However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps. The cool thing about Vercel Edge functions is that there's no cold start.

And not only that, but I'm getting consistently higher response times that I am on Firebase. The problem though is that testing from my own computer isn't a very good benchmark. What we need to do is test from servers all around the world. Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this. It makes requests from different locations around the world and measures the speed of the response time.

What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server. After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia. Why is that? Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa. Dallas got the fastest response time because it's only 500 miles away.

New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away. Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there. Good luck explaining that one, globetards. Fatality. Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world.

Like Sydney was actually twice as fast as Dallas. Bangalore once again has a high response time, but that's mostly due to a long DNS lookup. So the edge is clearly faster overall, but but here's where things get interesting. What if your edge function needs to query data from a database or API? Imagine you have an edge function in New Zealand, but your database lives in New York City.

In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand. The end result is a much longer round trip. You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand. To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response. In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request.

Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function. Council Bluffs, Iowa. Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio. When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world. The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow.

Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function. Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped. The bottom line is that the edge is much slower when remote data fetching is involved. The only way to avoid that is to also distribute our database around the world. There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis.

The cool thing about Next. Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes. It's not an all or nothing decision which really allows you to fine tune performance. Now, the other thing to keep in mind here is that you can also cache responses from functions. That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests.

Let's go ahead and benchmark that as well. In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes. When a new request comes in, it will send a response like normal and then cache it on the edge. That cached value will stay valid for 5 minutes before a new response is generated. That's important because it means it won't do that full round trip to the database if a cached version is already available.

Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well. To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly. That can be accomplished by rewriting a route and hosting to a cloud function. Then in the function code, I'm also setting a cache control header just like I did in the Vercel function. And now we can run our benchmark again.

What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds. At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast. But at this point, they're both so fast that the end user would never notice. I think the only way to properly describe it is blazingly them really fast. The one issue with Firebase functions though is that you still have the cold start.

However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month. And that's what it's like to live life on the edge. Living on the edge. If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO. Thanks for watching, and I will see you in the next one.
If all your friends jumped off the edge of a cliff, would you do it too? In today's video, we'll find out. All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions. And just a few days ago, Next. Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes. Sounds edgy, but what does that even mean? Is it some magic new way to make web apps faster or just marketing nonsense you can ignore. Coca Cola with a new taste, a new explosion of wonderfulness in your mouth. I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking.
But first, what even is edge computing? Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4. Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server.
computers
internet
infrastructure
technology
ibm
The problem is that your users are all around the world. The speed of light is fast, but not instant. So being physically closer is faster in theory. Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world. That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world. That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in. Edge computing changes that. It's like a CDN for a full blown server. That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world. As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users. Sounds awesome, but what's the catch? Well, in order for the system to scale, there needs to be a very minimal runtime. That means Node. Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box. You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte. That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge. What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages. All you have to do is export a configuration object from that route. It's nice to have that flexibility because what I'm about to say next might shock you. Edge computing is not always faster. In fact, it can be significantly lower in certain situations. Allow me to demonstrate. In this project, I have a Next JS app along with a Firebase Cloud Functions back end. I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP. The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next. Js code runs on Vercel's Edge network. In this first experiment, I have a function that simply returns a JSON response with the text of hello world. One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available. The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively. From there, I opened up Insomnia to test out both endpoints from my location in the United States. The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast. However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps. The cool thing about Vercel Edge functions is that there's no cold start. And not only that, but I'm getting consistently higher response times that I am on Firebase. The problem though is that testing from my own computer isn't a very good benchmark. What we need to do is test from servers all around the world. Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this. It makes requests from different locations around the world and measures the speed of the response time. What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server. After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia. Why is that? Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa. Dallas got the fastest response time because it's only 500 miles away. New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away. Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there. Good luck explaining that one, globetards. Fatality. Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world. Like Sydney was actually twice as fast as Dallas. Bangalore once again has a high response time, but that's mostly due to a long DNS lookup. So the edge is clearly faster overall, but but here's where things get interesting. What if your edge function needs to query data from a database or API? Imagine you have an edge function in New Zealand, but your database lives in New York City. In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand. The end result is a much longer round trip. You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand. To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response. In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request. Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function. Council Bluffs, Iowa. Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio. When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world. The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow. Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function. Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped. The bottom line is that the edge is much slower when remote data fetching is involved.
The only way to avoid that is to also distribute our database around the world. There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis. The cool thing about Next. Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes.
databases
data management
It's not an all or nothing decision which really allows you to fine tune performance. Now, the other thing to keep in mind here is that you can also cache responses from functions. That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests.
databases
data management
Let's go ahead and benchmark that as well. In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes. When a new request comes in, it will send a response like normal and then cache it on the edge. That cached value will stay valid for 5 minutes before a new response is generated. That's important because it means it won't do that full round trip to the database if a cached version is already available. Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well. To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly. That can be accomplished by rewriting a route and hosting to a cloud function. Then in the function code, I'm also setting a cache control header just like I did in the Vercel function. And now we can run our benchmark again. What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds. At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast. But at this point, they're both so fast that the end user would never notice. I think the only way to properly describe it is blazingly them really fast. The one issue with Firebase functions though is that you still have the cold start. However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month. And that's what it's like to live life on the edge. Living on the edge. If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO. Thanks for watching, and I will see you in the next one.
If all your friends jumped off the edge of a cliff, would you do it too? In today's video, we'll find out. All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions. And just a few days ago, Next. Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes. Sounds edgy, but what does that even mean? Is it some magic new way to make web apps faster or just marketing nonsense you can ignore. Coca Cola with a new taste, a new explosion of wonderfulness in your mouth. I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking. But first, what even is edge computing? Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4. Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server. The problem is that your users are all around the world. The speed of light is fast, but not instant. So being physically closer is faster in theory. Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world. That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world. That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in. Edge computing changes that. It's like a CDN for a full blown server. That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world. As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users. Sounds awesome, but what's the catch? Well, in order for the system to scale, there needs to be a very minimal runtime. That means Node. Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box. You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte. That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge. What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages. All you have to do is export a configuration object from that route. It's nice to have that flexibility because what I'm about to say next might shock you. Edge computing is not always faster. In fact, it can be significantly lower in certain situations. Allow me to demonstrate. In this project, I have a Next JS app along with a Firebase Cloud Functions back end. I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP. The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next. Js code runs on Vercel's Edge network. In this first experiment, I have a function that simply returns a JSON response with the text of hello world. One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available. The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively. From there, I opened up Insomnia to test out both endpoints from my location in the United States. The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast. However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps. The cool thing about Vercel Edge functions is that there's no cold start. And not only that, but I'm getting consistently higher response times that I am on Firebase. The problem though is that testing from my own computer isn't a very good benchmark. What we need to do is test from servers all around the world. Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this. It makes requests from different locations around the world and measures the speed of the response time. What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server. After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia. Why is that? Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa. Dallas got the fastest response time because it's only 500 miles away. New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away. Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there. Good luck explaining that one, globetards. Fatality. Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world. Like Sydney was actually twice as fast as Dallas. Bangalore once again has a high response time, but that's mostly due to a long DNS lookup. So the edge is clearly faster overall, but but here's where things get interesting. What if your edge function needs to query data from a database or API? Imagine you have an edge function in New Zealand, but your database lives in New York City. In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand. The end result is a much longer round trip. You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand. To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response. In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request. Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function. Council Bluffs, Iowa. Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio. When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world. The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow. Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function. Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped. The bottom line is that the edge is much slower when remote data fetching is involved. The only way to avoid that is to also distribute our database around the world. There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis. The cool thing about Next. Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes. It's not an all or nothing decision which really allows you to fine tune performance. Now, the other thing to keep in mind here is that you can also cache responses from functions. That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests. Let's go ahead and benchmark that as well. In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes. When a new request comes in, it will send a response like normal and then cache it on the edge. That cached value will stay valid for 5 minutes before a new response is generated. That's important because it means it won't do that full round trip to the database if a cached version is already available. Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well. To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly. That can be accomplished by rewriting a route and hosting to a cloud function. Then in the function code, I'm also setting a cache control header just like I did in the Vercel function. And now we can run our benchmark again. What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds. At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast. But at this point, they're both so fast that the end user would never notice. I think the only way to properly describe it is blazingly them really fast. The one issue with Firebase functions though is that you still have the cold start. However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month. And that's what it's like to live life on the edge. Living on the edge. If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO. Thanks for watching, and I will see you in the next one.
If
if
all
all
your
your
friends
friends
jumped
jumped
off
off
the
the
edge
edge
of
of
a
a
cliff,
cliff
would
would
you
you
do
do
it
it
too?
too
In
in
today's
today's
video,
video
we'll
we'll
find
find
out.
out
All
all
the
the
hot
hot
new
new
game
game
changing
changing
frameworks
frameworks
talk
talk
about
about
their
their
ability
ability
to
to
run
run
on
on
the
the
edge,
edge
using
using
serverless
serverless
computing
computing
platforms
platforms
like
like
Cloudflare
cloudflare
Workers
workers
and
and
Vercel
vercel
Edge
edge
Functions.
functions
And
and
just
just
a
a
few
few
days
days
ago,
ago
Next.
next
Js
js
release
release
version
version
12.2
12.2
with
with
the
the
ability
ability
to
to
opt
opt
into
into
the
the
edge
edge
for
for
server
server
side
side
rendering
rendering
and
and
API
api
routes.
routes
Sounds
sounds
edgy,
edgy
but
but
what
what
does
does
that
that
even
even
mean?
mean
Is
is
it
it
some
some
magic
magic
new
new
way
way
to
to
make
make
web
web
apps
apps
faster
faster
or
or
just
just
marketing
marketing
nonsense
nonsense
you
you
can
can
ignore.
ignore
Coca
coca
Cola
cola
with
with
a
a
new
new
taste,
taste
a
a
new
new
explosion
explosion
of
of
wonderfulness
wonderfulness
in
in
your
your
mouth.
mouth
I
i
did
did
some
some
actual
actual
benchmarking
benchmarking
between
between
Vercel
vercel
Edge
edge
Functions
functions
and
and
Firebase
firebase
Cloud
cloud
Functions
functions
to
to
find
find
out
out
which
which
one
one
is
is
faster
faster
in
in
the
the
real
real
world,
world
and
and
the
the
results
results
are
are
absolutely
absolutely
mocking.
mocking
But
but
first,
first
what
what
even
even
is
is
edge
edge
computing?
computing
Well,
well
traditionally,
traditionally
when
when
you
you
deploy
deploy
a
a
web
web
app,
app
you
you
rent
rent
out
out
a
a
computer
computer
that
that
lives
lives
in
in
a
a
physical
physical
data
data
center
center
somewhere
somewhere
around
around
world
world
like
like
US
us
East
east
2,
2
Africa
africa
South
south
1,
1
or
or
Tatooine
tatooine
West
west
4.
4
Because
because
you're
you're
poor,
poor
you
you
can
can
only
only
afford
afford
this
this
one
one
virtual
virtual
machine,
machine
so
so
all
all
requests
requests
around
around
the
the
world
world
go
go
to
to
that
that
same
same
server.
server
The
the
problem
problem
is
is
that
that
your
your
users
users
are
are
all
all
around
around
the
the
world.
world
The
the
speed
speed
of
of
light
light
is
is
fast,
fast
but
but
not
not
instant.
instant
So
so
being
being
physically
physically
closer
closer
is
is
faster
faster
in
in
theory.
theory
Web
web
developers
developers
have
have
known
known
about
about
this
this
problem
problem
for
for
a
a
long
long
time
time
and
and
have
have
been
been
using
using
content
content
delivery
delivery
networks
networks
to
to
distribute,
distribute
duplicate,
duplicate
or
or
cache
cache
static
static
files
files
like
like
HTML,
html
CSS,
css
Sass
sass
and
and
jQuery
jquery
on
on
servers
servers
all
all
around
around
the
the
world.
world
That
that
means
means
if
if
someone
someone
from
from
Sri
sri
Lanka
lanka
visits
visits
your
your
website,
website
they
they
get
get
an
an
image
image
hosted
hosted
in
in
Bangladesh
bangladesh
as
as
opposed
opposed
to
to
Iowa
iowa
on
on
the
the
other
other
side
side
of
of
the
the
world.
world
That's
that's
awesome
awesome
for
for
static
static
files,
files
but
but
it
it
doesn't
doesn't
really
really
work
work
when
when
you
you
have
have
a
a
dynamic
dynamic
server
server
that
that
needs
needs
to
to
execute
execute
some
some
code
code
when
when
a
a
request
request
comes
comes
in.
in
Edge
edge
computing
computing
changes
changes
that.
that
It's
it's
like
like
a
a
CDN
cdn
for
for
a
a
full
full
blown
blown
server.
server
That
that
means
means
when
when
you
you
hit
hit
deploy,
deploy
it
it
doesn't
doesn't
just
just
go
go
to
to
a
a
single
single
data
data
center,
center
but
but
is
is
distributed
distributed
all
all
around
around
the
the
world.
world
As
as
a
a
developer,
developer
they
they
work
work
just
just
like
like
serverless
serverless
functions
functions
like
like
AWS
aws
Lambda,
lambda
but
but
without
without
cold
cold
starts
starts
and
and
are
are
executed
executed
closer
closer
to
to
your
your
end
end
users.
users
Sounds
sounds
awesome,
awesome
but
but
what's
what's
the
the
catch?
catch
Well,
well
in
in
order
order
for
for
the
the
system
system
to
to
scale,
scale
there
there
needs
needs
to
to
be
be
a
a
very
very
minimal
minimal
runtime.
runtime
That
that
means
means
Node.
node
Js
js
and
and
the
the
1,000,000
1,000,000
npm
npm
packages
packages
you
you
have
have
installed
installed
aren't
aren't
going
going
to
to
work,
work
at
at
least
least
not
not
out
out
of
of
the
the
box.
box
You'll
you'll
have
have
to
to
bundle
bundle
them
them
with
with
webpack,
webpack
and
and
the
the
total
total
size
size
of
of
your
your
bundled
bundled
code
code
can't
can't
exceed
exceed
1
1
megabyte.
megabyte
That
that
requirement
requirement
can
can
disqualify
disqualify
a
a
lot
lot
of
of
applications,
applications
but
but
the
the
good
good
news
news
is
is
that
that
many
many
modern
modern
full
full
stack
stack
frameworks
frameworks
like
like
Sveltekit,
sveltekit
Nuxt
nuxt
JS,
js
and
and
now
now
Next
next
JS
js
have
have
implemented
implemented
the
the
ability
ability
to
to
render
render
on
on
the
the
edge.
edge
What's
what's
especially
especially
cool
cool
about
about
XJS
xjs
is
is
that
that
it
it
gives
gives
you
you
the
the
ability
ability
to
to
opt
opt
into
into
the
the
edge
edge
on
on
specific
specific
API
api
routes
routes
or
or
pages.
pages
All
all
you
you
have
have
to
to
do
do
is
is
export
export
a
a
configuration
configuration
object
object
from
from
that
that
route.
route
It's
it's
nice
nice
to
to
have
have
that
that
flexibility
flexibility
because
because
what
what
I'm
i'm
about
about
to
to
say
say
next
next
might
might
shock
shock
you.
you
Edge
edge
computing
computing
is
is
not
not
always
always
faster.
faster
In
in
fact,
fact
it
it
can
can
be
be
significantly
significantly
lower
lower
in
in
certain
certain
situations.
situations
Allow
allow
me
me
to
to
demonstrate.
demonstrate
In
in
this
this
project,
project
I
i
have
have
a
a
Next
next
JS
js
app
app
along
along
with
with
a
a
Firebase
firebase
Cloud
cloud
Functions
functions
back
back
end.
end
I'll
i'll
be
be
comparing
comparing
Next
next
JS
js
API
api
routes,
routes
which
which
get
get
deployed
deployed
as
as
serverless
serverless
functions
functions
to
to
Firebase
firebase
Cloud
cloud
Functions
functions
that
that
run
run
on
on
HTTP.
http
The
the
main
main
difference
difference
is
is
that
that
Firebase
firebase
runs
runs
on
on
the
the
Google
google
Cloud
cloud
Platform
platform
infrastructure,
infrastructure
while
while
the
the
Next.
next
Js
js
code
code
runs
runs
on
on
Vercel's
vercel's
Edge
edge
network.
network
In
in
this
this
first
first
experiment,
experiment
I
i
have
have
a
a
function
function
that
that
simply
simply
returns
returns
a
a
JSON
json
response
response
with
with
the
the
text
text
of
of
hello
hello
world.
world
One
one
thing
thing
that's
that's
worth
worth
noting
noting
is
is
that
that
you'll
you'll
notice
notice
in
in
the
the
Firebase
firebase
function,
function
we're
we're
using
using
express
express
JS
js
to
to
handle
handle
that,
that
but
but
in
in
the
the
Vercel
vercel
function,
function
we're
we're
using
using
web
web
APIs
apis
because
because
our
our
npm
npm
packages
packages
and
and
core
core
node
node
modules
modules
are
are
not
not
available.
available
The
the
The
the
next
next
thing
thing
I
i
did
did
is
is
deployed
deployed
both
both
back
back
ends
ends
to
to
the
the
cloud
cloud
using
using
Firebase
firebase
Deploy
deploy
and
and
Vercel
vercel
Deploy
deploy
respectively.
respectively
From
from
there,
there
I
i
opened
opened
up
up
Insomnia
insomnia
to
to
test
test
out
out
both
both
endpoints
endpoints
from
from
my
my
location
location
in
in
the
the
United
united
States.
states
The
the
firebase
firebase
function
function
generally
generally
gives
gives
a
a
response
response
time
time
of
of
around
around
a
a
150
150
milliseconds,
milliseconds
switch
switch
is
is
pretty
pretty
fast.
fast
However,
however
it
it
is
is
subject
subject
to
to
cold
cold
starts,
starts
which
which
means
means
that
that
if
if
it's
it's
not
not
been
been
used
used
recently,
recently
you
you
can
can
expect
expect
response
response
times
times
that
that
go
go
beyond
beyond
3
3
or
or
4
4
seconds,
seconds
which
which
is
is
not
not
fast
fast
and
and
could
could
be
be
a
a
a
a
deal
deal
breaker
breaker
for
for
certain
certain
types
types
of
of
apps.
apps
The
the
cool
cool
thing
thing
about
about
Vercel
vercel
Edge
edge
functions
functions
is
is
that
that
there's
there's
no
no
cold
cold
start.
start
And
and
not
not
only
only
that,
that
but
but
I'm
i'm
getting
getting
consistently
consistently
higher
higher
response
response
times
times
that
that
I
i
am
am
on
on
Firebase.
firebase
The
the
problem
problem
though
though
is
is
that
that
testing
testing
from
from
my
my
own
own
computer
computer
isn't
isn't
a
a
very
very
good
good
benchmark.
benchmark
What
what
we
we
need
need
to
to
do
do
is
is
test
test
from
from
servers
servers
all
all
around
around
the
the
world.
world
Luckily,
luckily
there's
there's
a
a
free
free
tool
tool
on
on
the
the
Internet
internet
for
for
debugging
debugging
CDN
cdn
issues
issues
that's
that's
perfect
perfect
for
for
testing
testing
stuff
stuff
like
like
this.
this
It
it
makes
makes
requests
requests
from
from
different
different
locations
locations
around
around
the
the
world
world
and
and
measures
measures
the
the
speed
speed
of
of
the
the
response
response
time.
time
What
what
we're
we're
most
most
interested
interested
in
in
is
is
the
the
time
time
to
to
first
first
byte,
byte
which
which
is
is
basically
basically
the
the
amount
amount
of
of
time
time
it
it
takes
takes
for
for
us
us
to
to
get
get
our
our
data
data
from
from
the
the
server.
server
After
after
running
running
it
it
on
on
both
both
back
back
ends,
ends
we
we
can
can
see
see
that
that
fire
fire
base
base
is
is
very
very
fast
fast
in
in
the
the
United
united
States,
states
it's
it's
a
a
little
little
bit
bit
slower
slower
in
in
Europe,
europe
and
and
a
a
lot
lot
slower
slower
in
in
Japan
japan
and
and
Australia.
australia
Why
why
is
is
that?
that
Well,
well
this
this
cloud
cloud
function
function
is
is
hosted
hosted
in
in
Google's
google's
US
us
Central
central
1,
1
which
which
is
is
in
in
Council
council
Bluffs,
bluffs
Iowa.
iowa
Dallas
dallas
got
got
the
the
fastest
fastest
response
response
time
time
because
because
it's
it's
only
only
500
500
miles
miles
away.
away
New
new
York
york
was
was
second,
second
which
which
is
is
a
a
1000
1000
miles
miles
away,
away
and
and
then
then
San
san
Francisco
francisco
is
is
3rd,
3rd
which
which
is
is
about
about
1500
1500
miles
miles
away.
away
Bangalore
bangalore
was
was
the
the
slowest,
slowest
which
which
is
is
interesting
interesting
because
because
technically
technically
it's
it's
closer
closer
than
than
Sydney,
sydney
and
and
I
i
think
think
the
the
only
only
logical
logical
explanation
explanation
is
is
that
that
the
the
Earth
earth
is
is
actually
actually
flat,
flat
requiring
requiring
longer
longer
underwater
underwater
cables
cables
to
to
get
get
there.
there
Good
good
luck
luck
explaining
explaining
that
that
one,
one
globetards.
globetards
Fatality.
fatality
Now,
now
if
if
we
we
look
look
at
at
the
the
Vercel
vercel
Edge
edge
function
function
results,
results
we
we
get
get
more
more
consistently
consistently
fast
fast
response
response
times
times
around
around
the
the
world.
world
Like
like
Sydney
sydney
was
was
actually
actually
twice
twice
as
as
fast
fast
as
as
Dallas.
dallas
Bangalore
bangalore
once
once
again
again
has
has
a
a
high
high
response
response
time,
time
but
but
that's
that's
mostly
mostly
due
due
to
to
a
a
long
long
DNS
dns
lookup.
lookup
So
so
the
the
edge
edge
is
is
clearly
clearly
faster
faster
overall,
overall
but
but
but
but
here's
here's
where
where
things
things
get
get
interesting.
interesting
What
what
if
if
your
your
edge
edge
function
function
needs
needs
to
to
query
query
data
data
from
from
a
a
database
database
or
or
API?
api
Imagine
imagine
you
you
have
have
an
an
edge
edge
function
function
in
in
New
new
Zealand,
zealand
but
but
your
your
database
database
lives
lives
in
in
New
new
York
york
City.
city
In
in
that
that
case,
case
the
the
edge
edge
function
function
will
will
need
need
to
to
go
go
all
all
the
the
way
way
to
to
New
new
York
york
City,
city
then
then
all
all
the
the
way
way
back
back
to
to
New
new
Zealand.
zealand
The
the
end
end
result
result
is
is
a
a
much
much
longer
longer
round
round
trip.
trip
You'd
you'd
actually
actually
be
be
much
much
better
better
off
off
with
with
just
just
a
a
single
single
server
server
close
close
to
to
your
your
database
database
in
in
New
new
York
york
City,
city
even
even
if
if
the
the
request
request
came
came
from
from
New
new
Zealand.
zealand
To
to
demonstrate
demonstrate
this,
this
I've
i've
created
created
some
some
data
data
in
in
Google's
google's
Firestore
firestore
database,
database
then
then
I
i
created
created
a
a
new
new
Vercel
vercel
function
function
that
that
requests
requests
this
this
data
data
from
from
the
the
Firestore
firestore
REST
rest
API
api
using
using
fetch
fetch
and
and
returns
returns
it
it
as
as
the
the
response.
response
In
in
the
the
Firebase
firebase
function,
function
I'm
i'm
doing
doing
basically
basically
the
the
same
same
thing,
thing
but
but
instead
instead
using
using
the
the
Firebase
firebase
Admin
admin
SDK
sdk
to
to
make
make
the
the
request.
request
Now,
now
when
when
data
data
fetching
fetching
is
is
involved,
involved
Firebase
firebase
has
has
a
a
huge
huge
advantage
advantage
because
because
the
the
data
data
lives
lives
in
in
the
the
same
same
exact
exact
data
data
center
center
as
as
the
the
cloud
cloud
function.
function
Council
council
Bluffs,
bluffs
Iowa.
iowa
Vercel's
vercel's
edge
edge
network
network
is
is
built
built
on
on
top
top
of
of
AWS,
aws
so
so
the
the
closest
closest
it
it
can
can
get
get
is
is
Cleveland,
cleveland
Ohio.
ohio
When
when
we
we
run
run
the
the
test
test
again,
again
you
you
can
can
see
see
that
that
Firebase
firebase
got
got
a
a
little
little
bit
bit
slower
slower
with
with
data
data
fetching,
fetching
but
but
the
the
trend
trend
is
is
the
the
same
same
where
where
it's
it's
faster
faster
in
in
the
the
United
united
States
states
than
than
it
it
is
is
elsewhere
elsewhere
in
in
the
the
world.
world
The
the
crazy
crazy
thing
thing
though
though
is
is
that
that
when
when
we
we
run
run
this
this
test
test
on
on
Vercel,
vercel
not
not
only
only
did
did
it
it
get
get
slower,
slower
but
but
it
it
got
got
to
to
the
the
point
point
of
of
being
being
unacceptably
unacceptably
slow.
slow
Like,
like
Sydney
sydney
now
now
has
has
a
a
full
full
one
one
second
second
response
response
time,
time
which
which
is
is
more
more
than
than
10
10
times
times
slower
slower
than
than
it
it
was
was
previously
previously
and
and
about
about
3
3
times
times
slower
slower
than
than
the
the
fire
fire
based
based
function.
function
Somehow,
somehow
Bangalore
bangalore
got
got
faster,
faster
which
which
means
means
the
the
Earth
earth
must
must
not
not
be
be
flat
flat
Geralt
geralt
and
and
is
is
in
in
fact
fact
donut
donut
shaped.
shaped
The
the
bottom
bottom
line
line
is
is
that
that
the
the
edge
edge
is
is
much
much
slower
slower
when
when
remote
remote
data
data
fetching
fetching
is
is
involved.
involved
The
the
only
only
way
way
to
to
avoid
avoid
that
that
is
is
to
to
also
also
distribute
distribute
our
our
database
database
around
around
the
the
world.
world
There
there
are
are
databases
databases
designed
designed
to
to
do
do
that
that
like
like
Cassandra,
cassandra
or
or
you
you
might
might
use
use
a
a
secondary
secondary
database
database
as
as
a
a
cache
cache
like
like
Redis.
redis
The
the
cool
cool
thing
thing
about
about
Next.
next
Js
js
is
is
that
that
its
its
engineers
engineers
are
are
well
well
aware
aware
this
this
and
and
that's
that's
why
why
they
they
allow
allow
you
you
to
to
opt
opt
into
into
Edge
edge
functions
functions
on
on
specific
specific
routes.
routes
It's
it's
not
not
an
an
all
all
or
or
nothing
nothing
decision
decision
which
which
really
really
allows
allows
you
you
to
to
fine
fine
tune
tune
performance.
performance
Now,
now
the
the
other
other
thing
thing
to
to
keep
keep
in
in
mind
mind
here
here
is
is
that
that
you
you
can
can
also
also
cache
cache
responses
responses
from
from
functions.
functions
That
that
means
means
if
if
your
your
database
database
is
is
far
far
away,
away
you
you
can
can
cache
cache
the
the
initial
initial
response
response
so
so
you
you
don't
don't
have
have
to
to
make
make
the
the
full
full
round
round
trip
trip
on
on
all
all
subsequent
subsequent
requests.
requests
Let's
let's
go
go
ahead
ahead
and
and
benchmark
benchmark
that
that
as
as
well.
well
In
in
the
the
Vercel
vercel
function,
function
I'm
i'm
going
going
to
to
use
use
the
the
most
most
basic
basic
form
form
of
of
caching
caching
by
by
setting
setting
a
a
cache
cache
control
control
header
header
that
that
has
has
a
a
max
max
age
age
of
of
300
300
seconds
seconds
4
4
or
or
5
5
minutes.
minutes
When
when
a
a
new
new
request
request
comes
comes
in,
in
it
it
will
will
send
send
a
a
response
response
like
like
normal
normal
and
and
then
then
cache
cache
it
it
on
on
the
the
edge.
edge
That
that
cached
cached
value
value
will
will
stay
stay
valid
valid
for
for
5
5
minutes
minutes
before
before
a
a
new
new
response
response
is
is
generated.
generated
That's
that's
important
important
because
because
it
it
means
means
it
it
won't
won't
do
do
that
that
full
full
round
round
trip
trip
to
to
the
the
database
database
if
if
a
a
cached
cached
version
version
is
is
already
already
available.
available
Now
now
what
what
might
might
surprise
surprise
you
you
is
is
that
that
Firebase
firebase
Cloud
cloud
Functions
functions
can
can
also
also
cache
cache
sponsors
sponsors
on
on
the
the
edge
edge
as
as
well.
well
To
to
do
do
that,
that
we
we
have
have
to
to
route
route
them
them
through
through
Firebase
firebase
Hosting,
hosting
which
which
has
has
a
a
built
built
in
in
CDN
cdn
powered
powered
by
by
Fastly.
fastly
That
that
can
can
be
be
accomplished
accomplished
by
by
rewriting
rewriting
a
a
route
route
and
and
hosting
hosting
to
to
a
a
cloud
cloud
function.
function
Then
then
in
in
the
the
function
function
code,
code
I'm
i'm
also
also
setting
setting
a
a
cache
cache
control
control
header
header
just
just
like
like
I
i
did
did
in
in
the
the
Vercel
vercel
function.
function
And
and
now
now
we
we
can
can
run
run
our
our
benchmark
benchmark
again.
again
What
what
you'll
you'll
notice
notice
is
is
that
that
they're
they're
both
both
extremely
extremely
fast,
fast
delivering
delivering
responses
responses
between
between
10
10
50
50
milliseconds.
milliseconds
At
at
this
this
point,
point
we're
we're
basically
basically
just
just
comparing
comparing
the
the
speed
speed
of
of
their
their
CDNs,
cdns
and
and
based
based
on
on
my
my
sample,
sample
it
it
looks
looks
like
like
Firebase
firebase
is
is
more
more
consistently
consistently
fast.
fast
But
but
at
at
this
this
point,
point
they're
they're
both
both
so
so
fast
fast
that
that
the
the
end
end
user
user
would
would
never
never
notice.
notice
I
i
think
think
the
the
only
only
way
way
to
to
properly
properly
describe
describe
it
it
is
is
blazingly
blazingly
them
them
really
really
fast.
fast
The
the
one
one
issue
issue
with
with
Firebase
firebase
functions
functions
though
though
is
is
that
that
you
you
still
still
have
have
the
the
cold
cold
start.
start
However,
however
it
it
is
is
possible
possible
to
to
run
run
them
them
with
with
a
a
minimum
minimum
number
number
of
of
instances,
instances
which
which
means
means
you
you
always
always
have
have
at
at
least
least
n
n
number
number
of
of
functions
functions
running,
running
therefore
therefore
no
no
cold
cold
starts,
starts
but
but
each
each
instance
instance
will
will
cost
cost
you
you
about
about
$5
$5
per
per
month.
month
And
and
that's
that's
what
what
it's
it's
like
like
to
to
live
live
life
life
on
on
the
the
edge.
edge
Living
living
on
on
the
the
edge.
edge
If
if
you
you
wanna
wanna
learn
learn
more
more
about
about
building
building
apps
apps
with
with
Next
next
and
and
Firebase
firebase
together,
together
check
check
out
out
my
my
full
full
course
course
on
on
Fireship
fireship
IO.
io
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speaker discusses edge computing, which involves using serverless computing platforms like Cloudflare Workforce and Vercel Edge Telescope to run web apps on the edge. Edge computing is fast, but requires minimal infrastructure, making it difficult to scale. XJS, a cloud function, allows for fast response times and fast data transfer, and is used in edge computing projects. The speaker explains the benefits of using edge computing, including the potential for faster data transfer and efficient edge computing.
Is "edge" computing really faster?
If all your friends jumped off the edge of a cliff, would you do it too? In today's video, we'll find out. All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions. And just a few days ago, Next. Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes. Sounds edgy, but what does that even mean? Is it some magic new way to make web apps faster or just marketing nonsense you can ignore. Coca Cola with a new taste, a new explosion of wonderfulness in your mouth. I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking. But first, what even is edge computing? Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4. Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server. The problem is that your users are all around the world. The speed of light is fast, but not instant. So being physically closer is faster in theory. Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world. That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world. That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in. Edge computing changes that. It's like a CDN for a full blown server. That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world. As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users. Sounds awesome, but what's the catch? Well, in order for the system to scale, there needs to be a very minimal runtime. That means Node. Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box. You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte. That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge. What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages. All you have to do is export a configuration object from that route. It's nice to have that flexibility because what I'm about to say next might shock you. Edge computing is not always faster. In fact, it can be significantly lower in certain situations. Allow me to demonstrate. In this project, I have a Next JS app along with a Firebase Cloud Functions back end. I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP. The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next. Js code runs on Vercel's Edge network. In this first experiment, I have a function that simply returns a JSON response with the text of hello world. One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available. The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively. From there, I opened up Insomnia to test out both endpoints from my location in the United States. The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast. However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps. The cool thing about Vercel Edge functions is that there's no cold start. And not only that, but I'm getting consistently higher response times that I am on Firebase. The problem though is that testing from my own computer isn't a very good benchmark. What we need to do is test from servers all around the world. Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this. It makes requests from different locations around the world and measures the speed of the response time. What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server. After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia. Why is that? Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa. Dallas got the fastest response time because it's only 500 miles away. New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away. Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there. Good luck explaining that one, globetards. Fatality. Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world. Like Sydney was actually twice as fast as Dallas. Bangalore once again has a high response time, but that's mostly due to a long DNS lookup. So the edge is clearly faster overall, but but here's where things get interesting. What if your edge function needs to query data from a database or API? Imagine you have an edge function in New Zealand, but your database lives in New York City. In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand. The end result is a much longer round trip. You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand. To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response. In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request. Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function. Council Bluffs, Iowa. Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio. When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world. The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow. Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function. Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped. The bottom line is that the edge is much slower when remote data fetching is involved. The only way to avoid that is to also distribute our database around the world. There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis. The cool thing about Next. Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes. It's not an all or nothing decision which really allows you to fine tune performance. Now, the other thing to keep in mind here is that you can also cache responses from functions. That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests. Let's go ahead and benchmark that as well. In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes. When a new request comes in, it will send a response like normal and then cache it on the edge. That cached value will stay valid for 5 minutes before a new response is generated. That's important because it means it won't do that full round trip to the database if a cached version is already available. Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well. To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly. That can be accomplished by rewriting a route and hosting to a cloud function. Then in the function code, I'm also setting a cache control header just like I did in the Vercel function. And now we can run our benchmark again. What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds. At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast. But at this point, they're both so fast that the end user would never notice. I think the only way to properly describe it is blazingly them really fast. The one issue with Firebase functions though is that you still have the cold start. However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month. And that's what it's like to live life on the edge. Living on the edge. If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO. Thanks for watching, and I will see you in the next one.
The speaker discusses edge computing, which involves using serverless computing platforms like Cloudflare Workforce and Vercel Edge Telescope to run web apps on the edge. Edge computing is fast, but requires minimal infrastructure, making it difficult to scale. XJS, a cloud function, allows for fast response times and fast data transfer, and is used in edge computing projects. The speaker explains the benefits of using edge computing, including the potential for faster data transfer and efficient edge computing.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Is "edge" computing really faster? 
        and a small summary : The speaker discusses edge computing, which involves using serverless computing platforms like Cloudflare Workforce and Vercel Edge Telescope to run web apps on the edge. Edge computing is fast, but requires minimal infrastructure, making it difficult to scale. XJS, a cloud function, allows for fast response times and fast data transfer, and is used in edge computing projects. The speaker explains the benefits of using edge computing, including the potential for faster data transfer and efficient edge computing.
        [/INST]
        
        Generate the video : If all your friends jumped off the edge of a cliff, would you do it too? In today's video, we'll find out. All the hot new game changing frameworks talk about their ability to run on the edge, using serverless computing platforms like Cloudflare Workers and Vercel Edge Functions. And just a few days ago, Next. Js release version 12.2 with the ability to opt into the edge for server side rendering and API routes. Sounds edgy, but what does that even mean? Is it some magic new way to make web apps faster or just marketing nonsense you can ignore. Coca Cola with a new taste, a new explosion of wonderfulness in your mouth. I did some actual benchmarking between Vercel Edge Functions and Firebase Cloud Functions to find out which one is faster in the real world, and the results are absolutely mocking. But first, what even is edge computing? Well, traditionally, when you deploy a web app, you rent out a computer that lives in a physical data center somewhere around world like US East 2, Africa South 1, or Tatooine West 4. Because you're poor, you can only afford this one virtual machine, so all requests around the world go to that same server. The problem is that your users are all around the world. The speed of light is fast, but not instant. So being physically closer is faster in theory. Web developers have known about this problem for a long time and have been using content delivery networks to distribute, duplicate, or cache static files like HTML, CSS, Sass and jQuery on servers all around the world. That means if someone from Sri Lanka visits your website, they get an image hosted in Bangladesh as opposed to Iowa on the other side of the world. That's awesome for static files, but it doesn't really work when you have a dynamic server that needs to execute some code when a request comes in. Edge computing changes that. It's like a CDN for a full blown server. That means when you hit deploy, it doesn't just go to a single data center, but is distributed all around the world. As a developer, they work just like serverless functions like AWS Lambda, but without cold starts and are executed closer to your end users. Sounds awesome, but what's the catch? Well, in order for the system to scale, there needs to be a very minimal runtime. That means Node. Js and the 1,000,000 npm packages you have installed aren't going to work, at least not out of the box. You'll have to bundle them with webpack, and the total size of your bundled code can't exceed 1 megabyte. That requirement can disqualify a lot of applications, but the good news is that many modern full stack frameworks like Sveltekit, Nuxt JS, and now Next JS have implemented the ability to render on the edge. What's especially cool about XJS is that it gives you the ability to opt into the edge on specific API routes or pages. All you have to do is export a configuration object from that route. It's nice to have that flexibility because what I'm about to say next might shock you. Edge computing is not always faster. In fact, it can be significantly lower in certain situations. Allow me to demonstrate. In this project, I have a Next JS app along with a Firebase Cloud Functions back end. I'll be comparing Next JS API routes, which get deployed as serverless functions to Firebase Cloud Functions that run on HTTP. The main difference is that Firebase runs on the Google Cloud Platform infrastructure, while the Next. Js code runs on Vercel's Edge network. In this first experiment, I have a function that simply returns a JSON response with the text of hello world. One thing that's worth noting is that you'll notice in the Firebase function, we're using express JS to handle that, but in the Vercel function, we're using web APIs because our npm packages and core node modules are not available. The The next thing I did is deployed both back ends to the cloud using Firebase Deploy and Vercel Deploy respectively. From there, I opened up Insomnia to test out both endpoints from my location in the United States. The firebase function generally gives a response time of around a 150 milliseconds, switch is pretty fast. However, it is subject to cold starts, which means that if it's not been used recently, you can expect response times that go beyond 3 or 4 seconds, which is not fast and could be a a deal breaker for certain types of apps. The cool thing about Vercel Edge functions is that there's no cold start. And not only that, but I'm getting consistently higher response times that I am on Firebase. The problem though is that testing from my own computer isn't a very good benchmark. What we need to do is test from servers all around the world. Luckily, there's a free tool on the Internet for debugging CDN issues that's perfect for testing stuff like this. It makes requests from different locations around the world and measures the speed of the response time. What we're most interested in is the time to first byte, which is basically the amount of time it takes for us to get our data from the server. After running it on both back ends, we can see that fire base is very fast in the United States, it's a little bit slower in Europe, and a lot slower in Japan and Australia. Why is that? Well, this cloud function is hosted in Google's US Central 1, which is in Council Bluffs, Iowa. Dallas got the fastest response time because it's only 500 miles away. New York was second, which is a 1000 miles away, and then San Francisco is 3rd, which is about 1500 miles away. Bangalore was the slowest, which is interesting because technically it's closer than Sydney, and I think the only logical explanation is that the Earth is actually flat, requiring longer underwater cables to get there. Good luck explaining that one, globetards. Fatality. Now, if we look at the Vercel Edge function results, we get more consistently fast response times around the world. Like Sydney was actually twice as fast as Dallas. Bangalore once again has a high response time, but that's mostly due to a long DNS lookup. So the edge is clearly faster overall, but but here's where things get interesting. What if your edge function needs to query data from a database or API? Imagine you have an edge function in New Zealand, but your database lives in New York City. In that case, the edge function will need to go all the way to New York City, then all the way back to New Zealand. The end result is a much longer round trip. You'd actually be much better off with just a single server close to your database in New York City, even if the request came from New Zealand. To demonstrate this, I've created some data in Google's Firestore database, then I created a new Vercel function that requests this data from the Firestore REST API using fetch and returns it as the response. In the Firebase function, I'm doing basically the same thing, but instead using the Firebase Admin SDK to make the request. Now, when data fetching is involved, Firebase has a huge advantage because the data lives in the same exact data center as the cloud function. Council Bluffs, Iowa. Vercel's edge network is built on top of AWS, so the closest it can get is Cleveland, Ohio. When we run the test again, you can see that Firebase got a little bit slower with data fetching, but the trend is the same where it's faster in the United States than it is elsewhere in the world. The crazy thing though is that when we run this test on Vercel, not only did it get slower, but it got to the point of being unacceptably slow. Like, Sydney now has a full one second response time, which is more than 10 times slower than it was previously and about 3 times slower than the fire based function. Somehow, Bangalore got faster, which means the Earth must not be flat Geralt and is in fact donut shaped. The bottom line is that the edge is much slower when remote data fetching is involved. The only way to avoid that is to also distribute our database around the world. There are databases designed to do that like Cassandra, or you might use a secondary database as a cache like Redis. The cool thing about Next. Js is that its engineers are well aware this and that's why they allow you to opt into Edge functions on specific routes. It's not an all or nothing decision which really allows you to fine tune performance. Now, the other thing to keep in mind here is that you can also cache responses from functions. That means if your database is far away, you can cache the initial response so you don't have to make the full round trip on all subsequent requests. Let's go ahead and benchmark that as well. In the Vercel function, I'm going to use the most basic form of caching by setting a cache control header that has a max age of 300 seconds 4 or 5 minutes. When a new request comes in, it will send a response like normal and then cache it on the edge. That cached value will stay valid for 5 minutes before a new response is generated. That's important because it means it won't do that full round trip to the database if a cached version is already available. Now what might surprise you is that Firebase Cloud Functions can also cache sponsors on the edge as well. To do that, we have to route them through Firebase Hosting, which has a built in CDN powered by Fastly. That can be accomplished by rewriting a route and hosting to a cloud function. Then in the function code, I'm also setting a cache control header just like I did in the Vercel function. And now we can run our benchmark again. What you'll notice is that they're both extremely fast, delivering responses between 10 50 milliseconds. At this point, we're basically just comparing the speed of their CDNs, and based on my sample, it looks like Firebase is more consistently fast. But at this point, they're both so fast that the end user would never notice. I think the only way to properly describe it is blazingly them really fast. The one issue with Firebase functions though is that you still have the cold start. However, it is possible to run them with a minimum number of instances, which means you always have at least n number of functions running, therefore no cold starts, but each instance will cost you about $5 per month. And that's what it's like to live life on the edge. Living on the edge. If you wanna learn more about building apps with Next and Firebase together, check out my full course on Fireship IO. Thanks for watching, and I will see you in the next one.
        