Pushing Boundaries to the Edge

Hello, everyone. My name is Facundo, and today we will talk about the Edge. First of all, I want to introduce myself. As I said, my name is Facundo, Facundo Giuliani. I'm from Argentina. I'm a Developer Relations Manager. I'm the manager of the Developer Relations Team at Storyblok. I'm also one of the organizers of React Buenos Aires. React Buenos Aires is the biggest React community in Argentina, and we organize monthly meetups, and I'm also one of the organizers of Dev Summit Argentina, another community of developers in the country.

So for today I wanted to start a little bit with some 90s vibe. I wanted to discuss how the websites were created when they looked like this one, the Space Jam website. If you go to the Internet, you can see that it's still up and running and it's looking like this. But at this time in the 90s, the websites worked and they still work in this way. You have a web browser in your mobile device or your computer. You send a request to a web server, that web server executes the request, generates the content, and then it sends the content to you after processing your request and generating all the data and the content that you need to see the page that you are requesting. Actually, this web server is an actual computer living somewhere in the world. So this is an image from the past, from the 90s, but it used to be like this. I mean a computer that if you turn off, that computer, your website is not up and running anymore, so you need to be careful with the wires and things like that. But, yeah, I mean, that's the basic way of working of a web server and the websites. This way of working has an issue, although, and the issue is that we have our web server in one unique location where the people is sending their request and expecting that web server to process their request and send the data. What it means is that if we have multiple people, let's say thousands of people requesting the content or sending at the same time, we may be overloading this web server. And not only that, another thing that we have to consider is that these requests that we are sending from any part of the world, we have to travel to this unique location where the web server is located. And then all that time that it takes to get from your location to the web server, it will affect the performance and the load time of your web page. So that those are some issues that a basic server-side rendering logic has. The multiple people accessing to the same web server, and also the different parts of the world where that people is requesting the page.

So in order to solve this scenario, or in order to see a solution for this particular use case, after the year's new concept was defined, the concept of content delivery network, this is a group of geographically distributed servers that helps you to speed up the delivery of web content, bringing that content closer to where the users are. So basically, what we have with these CDNs, as they are called, is we have different servers, like the web servers that we were mentioning before. We have different web servers in different parts of the world and these web servers are improved to deliver static content to the users. So basically, what we will have in these different nodes, as they are called in this network, are static assets like images, videos, but also HTML files, CSS files and JavaScript files. So they are going to be host and cached in these different nodes of our network.

And when a user wants to request one of these resources, the request that they are sending will travel to the closest node of the network. So let's say that I live in Argentina and I have one of the nodes of this network in Brazil. Instead of sending my request and having to go to a web server located in the UK, let's say, my request will travel to the Brazil node of the network and then I will get all the resources from that node. This helps to reduce the bandwidth consumption because we won't be accessing all the users or all the visitors to the same web server, and we will have a better performance because of this and because of the request having to travel less, let's say, going to the closest node of the network. I mean, depending on your location, depending where the network has these nodes, and there will be more security because instead of accessing to the origin of the data or the content, your request will travel to different nodes without having to know which is the actual web server that is hosting your website.

Because one thing that I mentioned and you have to consider is that these CDNs, they work with static assets. That means that if we need to generate dynamic content or dynamic assets, or we need to generate these assets dynamically, somehow based on a logic that depends on the user, we will still need the origin server to do that. So as I was mentioning, these CDNs work with static content. That's why a new term was developed with the ERs, the static site generation. You may be familiar with frameworks like Gatsby or NGJS where you can generate static assets at build time, JavaScript files, CSS files and HTML files. The idea of this is that you are able to create a website that can be host in these CDNs, so you don't depend on an origin server. And having the same idea in mind, the concept of the JAMstack was developed, where the idea was to focus most of the logic of your websites on the static assets and managing the dynamic data with different approaches like APIs, serverless function, or small pieces of code that is running server side, but not your whole website living on the web server or having to wait for each request to be processed to return or deliver this content. But as you can see, there there's another issue now. And the issue is that we can only manage static content with the CDNs. So as I was mentioning before, if we need some dynamic data, or we need to generate a certain asset, that is not living or is not cached on the nodes of the CDN, we will have to send the request to the origin server. And there's where the performance issues start to appear again. We are lacking the security and the performance that we have with a CDN.

So having this issue in mind and other ideas and approaches and always trying to improve the situation, of course, the IT industry came up with a new concept, the concept of the edge. The edge is basically a distributed network architecture where the client data is processed as close to the originating source as possible. So that means that if we will use some data coming from our users or some context from our users, we can grab that context as close as possible from them the server-side logic closer to them, instead of having to send the request and all that information to an origin server and wait for the processing. So in this case, what we will have is basically using the same distribution that we had for a CDN, we will have different origin servers in the different locations. So if I need to process data coming from the users and I have a user from Argentina wanting to request a certain resource or sending a request, that request will be processed in the closest node of my edge network, which in this case could be again, Brazil, let's say, instead of having to send that request to one unique origin server that is living in a particular location of the world. So in this case, we will have our origin server replicated in different parts of the world, processing all the requests that are coming from the different users. One thing that you have to keep in mind is that when we are talking about the edge, it's not the same the edge as a serverless function, because even though that we will have some of the benefits that we have with the serverless functions, like we won't need DevOps because the servers are going to be managed by the provider and we are only going to pay for what we use. I mean, instead of having to pay for a dedicated web server, we will have our processing time defining how much we are going to pay for that. So that means that we won't have under utility of the web servers because the only processing that we will have is when the requests are coming and are being processed and executed. I mean, all of these are aspects that we can identify and consider on serverless functions. The thing is that the Edge is not only this because a serverless function can be deployed to a centralized web server. And if that's the case, we are going to have the same issue that we had before with the origin server. I mean, the unique origin server.

So the Edge is going to solve even issues that we may have with the serverless functions. I mean, the Edge would be a combination between what is a serverless function and the CDNs. We would have the possibility of executing server-side logic without having to configure or maintain these web servers. And on the other hand, we would have that logic living on different nodes of a certain network of web servers, executing the different requests that are coming from the users from different parts of the world.

So as you can see with the Edge, we will have some of the benefits that we already had with the CDNs, which are better performance and more security, but we will also have real-time insights or easy scalability because in this case, we won't have only the static assets. We will also have the possibility of running server-side logic and process the requests that are coming from the different users.

So you may be asking, what are some of the use cases that we can apply the Edge or use the Edge for? Okay, so as you can see, we can use Edge functions, well, or that will depend on the provider, but we can use this Edge logic or Edge computing for personalization, for instance, based on the different user or type of users that are visiting our website, we can deliver customized content for them, we can use geolocation show particular content on our website based on the location of the user that is visiting this website, we can also apply logics for AV testing, test different versions of our content or our pages based on certain aspects of the visitors, and we also can implement security logic, we can verify that the users that are visiting our website or that are accessing to a particular content that we are offering are who they claim to be using authentication or authorization that we can implement in this logic that is going to live on the Edge network.