Paul:
Hi, there. Welcome to Pod Rocket, a podcast brought to you by Log Rocket. Log Rocket combines session replay, error tracking, and product analytics to help software teams solve user reported issues, find those issues faster, and improve conversion and adoption. Get a free trial at logrocket.com today. Today, we have a special guest with us who has been on our podcast multiple times already, so he's a seasoned interviewee and he's a supporter of the show. Please welcome Anthony Campolo. He's the host of FS Jam, you might listen to it, where they go over the latest trends in full stack development. Today, we're going to be diving into the Edge. It might seem like a mysterious something to some, but it really is a universal backbone that powers the experience of the internet that we know today. Welcome to the podcast, Anthony. Excited to have you.

Anthony Campolo:
Hey, Paul. Thanks for having me back. It's great to be here.

Paul:
Last time we talked, we were talking about Web 3.0, and we were talking about nodes and serving a data layer. I guess today, the topic of conversation is quite similar. We're talking about the edge. For people who are coming to this podcast wanting to learn what the edge is, can you give an analogy or comparison that might help wrap their heads around it?

Anthony Campolo:
Yeah, sure. This is a common term you're hearing a lot, and it's becoming baked into the way we do like our serverless functions. You may be hearing about serverless edge functions these days. We're using Edge in a similar way, where the edge is about getting the compute closer to the user. The way you usually do this is by having some sort of distributed global CDN, or just multiple server farms that are all around the world. So wherever your user is, they have a small latency to get the data. Edgio is a CDN, and we have pretty much one of the largest networks or rallies up there with things like Akamai. It's really well integrated with the ISPs even, so for us, it's a way to really optimize the performance at that last mile to the user.

Paul:
I think it's important to note, we are going to be talking about Edgio today. That's the focal point of the technology that we're going to be talking about, but we introduced the podcast, in general, as talking about the edge. The edge is a pretty universal concept and abstraction layer in technology, and Edgio is where you're at right now, Anthony. Edgio, is this like an edge provider? Is that the correct way to summarize it?

Anthony Campolo:
Yeah, so let me try and fit this into the broader ecosystem. People who listen to this show are probably familiar with AWS, GCP, Azure. Those are your layer one clouds that are the base infra. Then you have things like Netlify, or Vercel, or Flight Control even, that build higher level abstractions on top. Edgio is... First off, it's many different things. It's kind of a streaming platform and a deployment platform at the same time, so let's separate those two and talk just about the application deployment platform. I think of it like giving you a Jamstack experience, in terms of how you have a really nice dashboard, you sync to a Git repo, you can push assets, but it's really made for enterprise, and for large scale, really big apps and websites who are going to be shipping millions of pages.
If you were to imagine a Netlify or a Vercel button. Instead of being static first, it's server first. You can build static assets and push those up as well, but really, it's going to assume actually you have a server to start with. That's why it can be a similar development experience to one of these other Jamstack providers, but the idea is that you don't really ever need to migrate off. Because you'll see this a lot, where people will grow to a certain extent, and then they'll be like, "Oh, now I got to migrate to AWS." But with Edgio, you're already on a network that kind of can scale with you.
The closest thing I would probably compare to is, it's a bit like working with CloudFlare combined with CloudFlare Pages, because CloudFlare Pages would be the equivalent of Edgio sites and Edgio applications. Then you also have the security and the networking layer there as well, which is the stuff that usually is handled for you with things like Netlify or Vercel. It's a little bit deeper into the stack with hopefully not introducing too much extra complexity, but is giving you extra capabilities.

Paul:
When somebody makes a deployment on Edgio, is this a deployment at a very high level I can think of replicated globally? It's geographically close to the users, and I can have control over a service site rendered environment a little bit deeper into the stack. Is this sort of a unique value that Edgio is offering versus just a Netlify deployment.

Anthony Campolo:
It's going to give you different staging environments, and then you'll be able to deploy too. If you want to deploy to specific regions, you can do that. Or if you want to just deploy it to the CDN itself, then you can do that as well. For the most part, when you're working with it, you're not going to have to think too much about regions when you're working with it. I think you can probably fine tune that type of stuff if you need to, but for the most part, you're able to just work with it and not have to really worry about, "When is this thing going to be on the Edge? When is this thing going to be at my Origin server," and you can assume that's going to be handled for you.

Paul:
Right on. What do you think are one of the most common misconceptions about architecting software on the Edge? If somebody were to reach for Edgio today, and they want to start building a very fast application that is content first? One that might stand out to me is if your application database, like maybe you don't have replicated RDSs everywhere. You have one central app database. That could be a geographical bottleneck. I'm curious, how does Edgio help developers with that, and what are some other misconceptions when architecting?

Anthony Campolo:
Yeah. There's definitely a trend, right now, to try and push as much stuff to the Edge as possible. With things like Fly.io being like the logical conclusion of this, where it's like, "Just run a docker container at the Edge," which also gives you a really nice simple mental model, but that's not really what you want to do unless you really are buying into that whole container lifestyle. With this, it's more so figuring out, "Where does the actual server rendering happen, and does that need to happen on the Edge or not," because that could be one sense where you don't want to have to run this code every time. "On the Edge, it needs to happen if." You could just run it once, and then push the results of that to your Edge CDN.
That's where I think the deployment platforms really can come in and help here. Is that, developers want to have the benefits of the Edge without having to necessarily think about how they need to architect their application, and at what point that handoff happens. With Edgio, they do have that storage kind of API, but for the most part, you'll be running a database kind of wherever. If you want to have one of these more kind of Edge-native databases, you can do that, or you can work with traditional, single origin server kind of database, and then that is going to hook into your Edgio application. With the Edgio application, you'll have conventions with a route file, where you can set cash headers and you can manage Edge configuration. We have the ability to do some of the things you do with CloudFlare Worker, or now stuff you see with Netlify. Edge handlers, where you'll change headers, or you'll reroute traffic, or you'll do that kind of stuff.
That is where you can run configuration kind of code on the Edge, but what's cool with Edgio, what does make it unique is: It's not using isolates, it's not having to spin up. There's no cold start. It runs like native Varnish, like actually just straight up machine code. I don't really know anything about Varnish. That's the thing that I know CDN people talk about. That's the fastest way to do stuff, just run it in Varnish. That's the underlying thing that it's working with.

Paul:
So very minimal, if you're saying no cold start times with some of the features that Edgio offers us. Is this something that you find persisting throughout the board with Edgio's offerings? Something that you would traditionally find a cold start, you don't have on the Edgio side?

Anthony Campolo:
That's really the idea. We're very, very heavily focused on performance, and this is one of the things that made me really interested in working for the company and getting involved in it. Because I think we're in this kind of zeitgeist moment in JavaScript, where a lot of frameworks are realizing how important performance is and how they need to think about performance from the beginning. You have so many new frameworks now. Either solid, or quick, or on the server side, Bun, that are saying, "Hey, we need to actually architect for performance from the very beginning, and then benchmark every single part along the way." We can't just make a nice developer experience build this app, and then once we have the app, be like, "Okay. How do we optimize this thing," because we're realizing now that kind of puts you in a pickle.

Paul:
Right. When you find yourself in that pickle, do you find that pushing things to the Edge, like a networking layer misconception, is very common? Like, the solution? People say, "Oh, I'm a developer. It works fine in my local," but when you actually put it out in the wild, that's when one little 10% lag on one step for every re-render causes a giant lag over time. Is this really the crux of the problem, you think?

Anthony Campolo:
That's not what I'm referring to right now. That's a big part of how the Edge helps the performance, but what I'm talking about right now with the frameworks is the single page application problem, and the large bundle problem, and the things that partial hydration and resumeability are meant to fix, because those are issues where there's just too much code. You can connect and get them that code really quickly, but then that means they get a bunch of code really fast that then takes a long time for their device to parse. That doesn't help anything. This is why I say, you got to think about this thing holistically. There's so many steps along the chain. There's the application itself, and there's how that gets delivered, and then it's how it functions on the device. We're saying, "Okay. If the framework can give us a small bundle, we will get that to the user instantly." That's how you get this really snappy experience, which is what you need for things like e-commerce.

Paul:
Do you feel like when you want to design an application to be Edge performant, and you're doing this balancing act of, "I don't want to ship too much code at the beginning, but I don't want to not have a rich user experience," or, "I don't want stale buttons, because I'm waiting for hydration to take." You're playing this balancing game with a bunch of levers, and the way you optimize that can be framework specific, or it can be vendor specific. Like for AWS, that's a classic trope, classic problem. Do you feel like the way we're designing applications now is very vendor lock and heavy for Edge optimizations, because at the end, you're relying on proprietary hardware that is deployed in a proprietary way that is finely tuned and finely optimized with an API. You really have to like lean into those APIs. Do you find there's a lot of vendor lock in, because if you're moving from CloudFlare or Fastly back over to Edgio, or vice versa, or it does it more in the architecting at the beginning?

Anthony Campolo:
I think we're in a better place now than we've ever been. This is something that I've been tracking for a while, that personal interest of mine with Redwood. There was a time back in like 2021 when I was researching how to get Redwood to run on the Edge, because Redwood is a monolithic GraphQL server. Having that be a cold start bottleneck was a huge issue for the framework, so it made a lot of sense to say, "Hey, if we can get this thing on a CloudFlare Worker, that is going to almost eliminate this entire issue, which is affecting every single one who's building these apps." Then you realize, "Wait a second, CloudFlare Workers doesn't run Node. I thought it ran V8, though." Then you go down this whole rabbit hole of what's the difference between V8 and Node. Then you learn about Deno, then you learn about JavaScript core, and then you realize that, "Okay. JavaScript code ain't just JavaScript code."
Like running JavaScript code is something that many different people have done in many different ways of building on many different pieces of technology that is not very portable. However, now we realize that this is an issue that we need to really solve, and there's more collaboration happening between groups like CloudFlare and Deno, who have the WinterCG group. The web time interoperable consortium, something like that. I forget the exact terminology, but that is about creating this runtime that is just standard JavaScript ECMA compliant kind of code, and uses web native APIs, and can hopefully become portable.
I'm not really sure how Edgio will fit into that kind of mission, because we're running Node. Then as I said, we have our own kind of specific configuration thing for our setting/configuring the CDN. It would be interesting to see what's going to happen once things like Bun, and Deno, and CloudFlare Workers start to become more interchangeable. I'm actually seeing this with frameworks now. There's like frameworks now that are being built to run on any of those, like it's portable between CloudFlare Worker, Deno, and Bun. There's one in particular that I can look up, but I think that this is going to become hopefully an actual real thing, where you can start porting from one runtime to the other. We're not quite there yet, but there's a lot of movement.

Paul:
If we have one universal runtime, that sort of breaks down some silos between being able to take one piece of your stack and have it on one provider versus have it on another provider, which is really nice. You don't want vendor locking, which is one thing I love about Flight Control. Like Flight Control, it almost defines a base set of interactions and pieces of hardware that need a efficiently delivered modern web application to have. You can take that in or out of AWS in a lot of different ways, those same concepts.

Anthony Campolo:
Yeah. Hono.js is the one I was thinking of, and then there's another one called Hat Tip. H-O-N-O-J-S.dev. It's a web framework for CloudFlare Workers, Deno, Bun, and others. Yeah, I think this is pretty cool. Because what it does is, it assumes everyone wants to work with an API that's going to be similar to Express, or CoA, or CloudFlare Workers. It kind of like tries to mash all those together into something that is similar to what we've been writing, but either is standards compliant, or will just be transformed into something that standards compliant, with a kind of lightweight library wrapper around it. I'm seeing a lot of these projects right now. I think Worktop was one that used to be out a while ago that was doing a similar thing. I definitely recommend people check these kind of things out, because I think this is a very big shift that we're right on the cusp of.

Paul:
Just to summarize, Anthony. The shift that we're entering right now is how we're deploying our applications, that's the topic?

Anthony Campolo:
It's leaving behind node APIs, hopefully, is the shift I'm referring to specifically, because that is the thing that everyone has been writing their stuff on node APIs. Then if you can run a node server anywhere, that's great, but that can't be run on the Edge because then you get the cold start issue. That is the thing that we're trying to fix right now with this universal Edge runtime kind of thing.

Paul:
It's really exciting to see frameworks come out, such as Astro as an example, where you can run on one runtime or another runtime. There's applications that are making themselves multiple, but to have that universal runtime is... Yeah. It still has to be seen, but it's coming.

Anthony Campolo:
Yeah. It partly just comes down to the framework authors and the deployment providers themselves. Once every deployment platform figures out how to run every framework, then everyone can look at the sum total of all this stuff and be like, "Okay. Here's the commonalities between all this. Here's the thing that everyone's doing kind of differently." That's what's been, I think, really good about having deployment platforms that are not framework specific and having frameworks that are not platforms specific. That seems to be also a big trend that I'm very happy to see, because I like just trying out lots of different things and combining different pieces of tech. If you go to like Edgio's docs, you'll see a guide for pretty much every single framework you can possibly think of.

Paul:
Since we're talking about user experience, and having the best loading time for your website, and the best content delivery on the Edge, right? Before we get into some other features of Edgio, I'm just going to take a quick pause here to remind listeners that this podcast, Pod Rocket, is brought to you by Log Rocket, and Log Rocket can help you understand exactly how your users are experiencing their user experience. You can keep track of sessions, errors, product analytics, frustration indicators. Algorithms and AI surface the most impactful issues affecting your users, so you can spend more time building a great product rather than hunting through your tools. Solve user reported issues, find those issues faster, and improve your conversion and adoption today with Log Rocket.
Stepping back into Edgio specifically, and the Edge to improve your user experience, one thing that I thought was really neat is the streaming offerings that Edgio has, because streaming is something that naturally goes hand in hand with the Edge. You're talking about fast updating content. You can permeate content out to the globe quite easily, but doing that quickly all the time can become expensive. How does Edgio begin to tackle this problem, Anthony, and what do you think are some of the most compelling use cases or conversation starters for the value that streaming has within the ecosystem?

Anthony Campolo:
The first thing we need to clarify is we're not talking about ACTP streaming here. This is actually video streaming. The history of how Edgio came together helps explain what's happening here. Edgio is actually a new company made up of three very old companies. Most of the things we've been talking about right now -- the Edgio applications, the deployment part of it, the site's performance and security part of it -- that is what used to be called Layer Zero. Layer Zero was this suite of tools, and they combined with Limelight and then EdgeCast. Those three companies have come together. They were more focused on video content, so we support sites like Daily Motion or Rumble, which is an up and coming YouTube competitor. \.
We're, at least first or second, largest video streaming platforms in the world. That is what makes it definitely totally unique from most of these other kind of platforms, which can hook into some sort of storage, but video is such a specific kind of problem to itself. That is why if you go to Edgio, you'll see these different kind of products. You'll see that we have the performance sites and security suite, but then we also have the media delivery and open edge suite. Those can all be combined into whatever kind of order or type of application you want to create.
If you want to bring in video stuff, you can do that. But if you want to just still build just a regular old blog or e-commerce site, you can do that. Going back to what I said, this is not something you would ever need to migrate off of. No matter what you want to build, no matter what kind of application or experience you want to create, it's all there for you. You don't necessarily have to dive into it all immediately, but it's not something where you're like, "Okay. I have this nice deployment platform, but then when I want X, Y and Z, I need to integrate tool X, Y and Z." It's all there.

Paul:
What do you think is an area that Edgio is currently working on and developing, that you think tackles some problems or offerings maybe that some other providers have, that you think might open up the doors for some applications that Edgio may not be the first-stop shop that people think of. That, "Oh, these features are coming out. It's going to enable more people onto the platform." What's in the works right now?

Anthony Campolo:
Yeah. I think having a really well-integrated experience in terms of how you actually test, and tune, and record performance. A lot of people right now, and I think especially a lot of beginning web developers, what they're taught is: You create a website. Once it works, you run it through Lighthouse or similar tool. You look at the scores it gives you, you look at the advice it gives you, and then you change the stuff it tells you to change until the numbers go up. Then once the numbers go up, then you dust your hands off. You're like, "All right, I did it. The site is performant." That's not really the whole story a lot of the times, because any type of measurement is only going to measure what it's measuring. There's actually things outside of Lighthouse that are going to be happening in an application that might not be getting captured.
You can have all 100s while still having a slow user experience, if you are having to do super slow page transitions and things like that. The real thing you want is RUM, real user monitoring, which doesn't run a synthetic test, because that's the other important thing about Lighthouse. Is that it's testing certain things, which gives it certain biases in terms of what it's scoring you on, but then it's actually not running the site, and having a user use it, and then telling you what the performance is. It's running it in a fictional kind of environment, where it's testing things out and seeing what the results are. For the most part, this works. It helps you optimize, and it helps you make your website better and faster, but it's not exactly the same as the experience an actual user will have if they just go and use your website.
What you want to do to get that is: You just have them use your website, and then you record how long it takes for stuff to happen. That's your thing. It's like an empirical method versus a rationalist method. You're actually going to gather data that tells you how fast or slow your site is. I remember the first time I learned this was a thing, I was like, "Why is that this weird obscure thing that almost no one I know is using? That seems like a thing we should all be using and Lighthouse should be a nice extra thing you can use." To me, it seems totally flipped around.

Paul:
Do you feel like Edgio is going to help developers and teams step into that testing space a little easier, since we're talking about what's new and upcoming?

Anthony Campolo:
Right now, this is not so much. The capabilities are already there, so it's very easy to get a script in. You have a tab in your dashboard specifically for this. The thing that I want to help people with is just explaining both the value of this, and then creating content around showing how to do it, because I feel like this should be more of a core skill that web developers have. Is like, how do you actually install these scripts onto your site to really monitor the performance, and then how do you run AB tests to see what the changes you're implementing, what the downstream effects are of that? That's the type of stuff that's already in there and you can do. The whole platform itself, there's a lot of different things you can do, so I really want to help draw that story out for users with the content I'll be creating.
Just showing how this is what's going to help us get out of this, going back to the single page application problem. As we get more comfortable building these workflows into our normal development environment, we're going to continue to get more and better visibility into all of the different aspects of our site's performance, and all the different ways we can tweak it and change it. Which things are actually going to be moving the needle, and which you're actually doing, but it doesn't actually make it faster? There's this term, like security theater. Probably performance theater is like, "Oh, I changed from this framework to this framework, so now it's faster." It's like, "Well, did you benchmark it? Is it faster? Do you actually know it's faster, or have you just been told this framework's faster?"

Paul:
My follow-up question to this was: Do you feel, Anthony, very strongly about there being a common silver bullet? I don't even want to call it silver bullet, but a common area of, we can call it a misconception, when people are trying to tackle this problem. One you just mentioned right here, which is relying on the words of others, which is like, "This framework says it's faster, so if I use it, it's going to be faster." Well, no. I mean, it depends on how your application's architected. There's a lot of other factors to look at. But do you, Anthony, have any uncommon opinions about this topic that you obviously are very excited about? You're going to be content on it for people, like a core skill that kind of flies by people.

Anthony Campolo:
Yeah. That's why I would say there is no silver bullet for performance. When you hear this whole "it depends" thing when it comes to engineering, this is an area where it depends so heavily on so many things. Both your use case and what you're trying to do, and what tech you're using. That's why for me, it's more about what are the mental models we need to get to be able to start to understand what does it depend on? Because when you have a new framework that comes out and says, "This is more performance," that can be true, but it's going to be more performant in a specific way. Just because it's going to be more performant for 90% of use cases, it might be less performant for 10% of use cases, and you need to know which one of those you're in.
Sometimes, you can migrate to a "faster framework" and make your application slower if you don't understand what that framework is doing, and so that's why everyone now is trying to understand basically what's partial hydration, what's react server components, and what is islands? How does all this stuff relate to each other? What is going to be the best approach, and how is that going to work into the DX? That really needs to be worked out on the framework level. Then once that's worked out, then all the deployment platforms can figure out how to make that really nice and easy. The thing I worry about is that we're not going to pick an approach, and we're just going to have all these different ways of shipping different amounts of JavaScript, and that's going to be extremely confusing for people and already is.
I'm hoping to see more consolidation around that, but this is the blessing and the curse of open source JavaScript. Is that, it's a free for all. It's a dancing landscape, which is a great term [inaudible 00:28:40] taught me. That there is no centrally planned thing that we can all say, "Okay. This is what we want to optimize on. Let's create a five-year plan, optimize on this metric." Everyone's going at it their own way, and hopefully, it will rise to the top. Or some will be good for certain use cases, some will be good for others. Something I've been saying is, I'm bringing it back. They used to say, "Svelte is for sites, React is for apps." I've been saying, "Astro is for sites, Quick is for apps," because I think those both represent...
Astro is the new kind of static side generator with a little bit of interactivity, whereas Quick is the new super interactive but still performant kind of tool. Then you have things like Solid, which kind of sits in both those camps, and then React server components now is finally getting some attention. That is the one that could have the biggest impact on the overall ecosystem, because if all of the React frameworks move to React server components, then all the other frameworks might then be like, "Okay. This seems kind of the model we're all going with." But if only Nuxt goes to the React server component and all the other React frameworks don't, then there'll be less of an incentive for non-React frameworks to adopt a similar or server component type model.

Paul:
Yeah. I mean, it's the leader. Line leader of the group, essentially. Anthony, if people wanted to hop into Edgio today, if they were in the user interface for the first time and they wanted to deploy a site, what are some of the immediate first sections, or buttons, or names that people might see just to make sure they're in the right spot?

Anthony Campolo:
Yeah, so go to docs.edg.io and check out just the basics. Or the sites feature, in particular. I think that's probably the easiest one to get set up. If you go to sites, and then frameworks, you can find a template for any of your favorite frameworks. We have some that are, we consider them "tier one support", which means they're being consistently updated with the new versions and getting the new features. These are essentially Nuxt and React proper. That will probably expand at a certain point, but then we also have templates for every other framework you can think of.
They may, or may not, be on the latest hotness. Or probably still on Astro 1.0 and not Astro 2.0, for example, but there's a good guide and template for each of those. Then you'll learn how to use like the layers, the Edgio CLI, and it's a really nice experience. If you happen to have your own framework you're building for whatever reason, you can actually use our connectors. You can actually build your own framework connector as well, which is really easy to do, and I kind of did a little bit of with Redwood back in the day. So yeah, I'll say check out that. Check out the sites. Then once you start kind of building that out, you can start checking out the performance, and the security features, and all that other stuff.

Paul:
Anthony, if people wanted to hear more from you, like we said at the beginning of the podcast, you've been on two other episodes with us here at Pod Rocket. Where do people follow you? On your Twitter or other postings?

Anthony Campolo:
Yeah. My handle is ajcwebdev all across the internet. I even have an ajcwebdev.com blog, now, built on Astro. Yeah. I'm on Twitter, I'm on GitHub, I'm on Twitch, and I love talking about this stuff. FS Jam is my podcast, where we cover all of these frameworks, and I've interviewed a lot of the framework authors. Then, I definitely need to mention JavaScript Jam. This is something that was already being run by the community team at Edgio when I joined, and it was actually one of the things that got me interested in the company. I'd been going to these weekly Twitter spaces they'd been doing. They've been doing them so long, they used to be clubhouses, but now they're Twitter spaces.
Every Wednesday at 12:00 PM Pacific, we have either an open mic where we talk about JavaScript news in the last week, or we have a specific guest and we interview them about whatever they're working on. I really enjoy those, because it is like a live podcast recording where you get these great guests, but anyone in the audience can come up, ask a question, and become part of the podcast. Then we have a weekly newsletter, where a lot of the material we talk about is sourced from. All that is at javascriptjam.com.

Paul:
Anthony, thank you for your time. For people who want to hear more, you can go check out Anthony's podcast, FS Jam. Hear more about the latest and greatest in the JavaScript ecosystem, and definitely check out the other two episodes at Pod Rocket. Thank you for your time, Anthony. It was a pleasure.

Anthony Campolo:
Yeah. Thanks, Paul. Always fun getting me back on Pod Rocket.