Is "edge" computing really faster?

Key Takeaways

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 vercell edge functions and just a few days ago next js released 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 vircell edge functions and firebase cloud functions to find out which one is faster in the real world and the results are absolutely shocking 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 the 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 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 run time that means nodejs and the million mpm 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 one megabyte that requirement can disqualify a lot of applications but the good news is that many modern full stack frameworks like sveltkit nux js and now next js have implemented the ability to render on the edge what's especially cool about next js 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 slower in certain situations allow me to demonstrate in this project i have a next.js app along with a firebase cloud functions backend i'll be comparing next js api routes which get deployed at 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 vercell'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 expressjs to handle that but in the versail function we're using web apis because our npm packages and core node modules are not available the next thing i did is deployed both back ends to the cloud using firebase deploy and vercell 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 hundred and fifty milliseconds which 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 three or four seconds which is not fast and could be a deal breaker for certain types of apps the cool thing about versailles edge functions is that there's no cold start and not only that but i'm getting consistently higher response times than 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 firebase 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 one 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 thousand miles away and then san francisco is third 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 versailles 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 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 cell 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 vercell'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 vercell not only did it get slower but it got to the point of being unacceptably slow like sydney now has a full 1 second response time which is more than 10 times slower than it was previously and about three times slower than the firebase function somehow bangalore got faster which means the earth must not be flat after all 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 your 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 nexjs is that its engineers are well aware of 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 versail 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 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 responses 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 versail function and now we can run our benchmark again what you'll notice is that they're both extremely fast delivering responses between 10 and 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 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 five dollars per month and that's what it's like to live life on the edge if you want to 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