Pushing Boundaries to the Edge

Hello everyone. My name is Facundo, and today we will talk about the Edge. First of all, I wanted to introduce myself. As I said, my name is Facundo, Facundo Giuliani. I'm from Buenos Aires, Argentina. I'm a Developer Relations Engineer at Storyblok. I'm also one of the organizers of React Buenos Aires, the biggest React community in Argentina. We run local meetups every month in the city. I'm also one of the organizers of Dev Summit Argentina, another developer community here in the country. So if you are around, let me know.

So before starting with the actual concept of the Edge, I wanted to introduce it. Evaluating or like reviewing how the things used to be in the past. So I mean, not only in the past, but nowadays, too, whenever we request a page or we are browsing a page from our browser, let's say in our mobile phone or our computer, what we do is we send the request to a web server. In the case of the original way the things used to be, the web server would process my request and will generate an HTML document that will deliver to my browser so I can see the page that I want to visit. The thing is that this request is being processed for every user that is requesting the page and that wants to visit the page, which can be okay, but it can also bring some issues. The issues are that if we have multiple people requesting the same page we will be overloading the server that is generating the content and the HTML documents. And not only that, we are also depending on where that web server is located. So the users will send the request, the request will travel to the specific location where that server is, and then we will have to wait for the HTML document to come back to your browser, let's say.

So if I have a web server located in Australia, because that's where my website is host, and I'm visiting from Argentina, my request will have to travel from Buenos Aires to Australia. And that, I mean depending on the distance that the request is traveling, it will affect the load time of my page. So having these couple of issues in mind, a new concept was developed with the years, which is the Content Delivery Network or CDNs, and these CDNs are a group of geographically distributed servers that speed up the delivery of content because we are bringing the content closer to the users. So basically a CDN is a network of servers that are called nodes, these nodes are going to replicate the content on each one of the locations of the different servers and the request from the users will travel to the closest node to get the content instead of having to go to a particular location or a particular web server. So in the same example that I mentioned before, if I have a CDN node in Brazil, let's say, my request instead of having to go to Australia and bring back the HTML page that I'm requesting it would travel to Brazil and get the same content. The benefits that the CDNs are bringing are that we are reducing the bandwidth consumption because we are not sending all the requests to the same web server. On the other hand, we would have better performance because of this reason and because of the reason of what I said, the request not having to go to one particular location in the world. And on the other hand, we will also have more security because the users won't be requesting the content to the specific web server that is generating the content, but they are going to request to the closest node that is hosting the specific content that we want to deliver. And when I say specific content, it's because the CDNs or the node the server nodes from the CDNs are improved to deliver static content. They can deliver static assets like HTML files, CSS files or JavaScript files. And that brought the attention a new concept called static site generation. Basically, it is about creating a website that is being generated and built during the process that we run to generate the static version of the different pages of our website.

So what we do is basically run this build process and it will generate all the pages of my website in a static form with static assets like HTML files, CSS files, and JavaScript files. And we can use that to host our website and use it and get the advantage of the CDNs.

But probably you are seeing here the issue and the issue is that the CDNs are planned to deliver static content. So what happens when I have dynamic content that needs to be generated for a particular user with particular conditions and for a particular request that is coming? Let's say I need to process one particular request and send content based on that request. If that's the case, we still have what we call an origin server on our CDN. This origin server is like the web server that we mentioned before that will process each request and will deliver the content or will deliver the result of the processing. But the thing is that again, this CDN, this network, has only one origin server, so if I'm requesting static content, it's fine. I can get it from the closest node from the network, but if I need dynamic content, I have to send the request to one particular origin server, and we are having the same issue that we had before.

So with this concept in mind, and after the web servers evolving and having new features and having new possibilities, a new concept was developed which is the concept of DH. DH is basically a distributed network, like the one that we have for the CDNs. But in this case we have an architecture where we are processing the client data as close to the source of that data as possible. So DH is basically evolving the CDNs to having origin servers, or kind of origin servers, let's say, where we have the CDN nodes. So besides delivering static content from our CDN nodes, we are also going to be able to process data and based on the dynamic processing or the server side logic that will process the data coming from the customers, we will be able to deliver dynamic content to them faster because we are doing it closer to the source of the data, which are the users.

So as you can see, we have some of the main benefits that we have also for CDNs which are better performance, more security, but we also are going to have real time insights and easy scalability because we can add more edge servers, as they are called, to our network and we will be able to process requests from more users from different locations. So these edge networks, some of the main use cases that we can solve with edge computing, let's say or an edge network are personalization. We can evaluate the request of the users. And based on certain parameters that we are defining, we can return a certain content or a different content. We can also apply geolocation based on the location of the user that is visiting our website. We can return certain content or show a particular part of our web page. We can also implement A-B testing strategies of A-B testing if we are evaluating to release a new campaign on our website. Using this dynamic processing of the request we can show a particular version of the content or the other. And finally, we can also manage the security. We can apply authentication or authorization dynamically and we can evaluate which users are visiting our website. And based on that, show particular content, show validation, some things like that.

So as we are discussing the concept of the Edge, which is also tied to the web provider or the web server that we are going to use or the hosting provider that we are going to use to host our website. We also have to keep in mind the framework that we are going to use to create the code and the application itself that will be host on the Edge. As we are in React Berlin I will mention how a couple of React based frameworks are managing the concept of the Edge and the features that they offer us to manage that. One of the frameworks is NetJS. NetJS offers what they call Edge functions, which are basically serverless scripts. I mean scripts that you don't have to worry about the maintenance of the web server that are executed server-side, I mean they execute server-side rendering that can be distributed to different regions.

So these Edge servers that we mentioned across the whole network, all of them will be able to execute this server-side rendering logic. We also have the possibility of implementing what they call a middleware. A middleware is an intermediate tier that will execute custom logic for every request that is sent to the server.

So whenever a user is sending a request, we have the possibility of executing custom logic based on that request before the actual request is processed and the content that is planned to be delivered is actually delivered. So these are a couple of concepts that NetJS is offering.

On the other hand, Remix, another React-based framework, they have what they call the Net Generation Edge, which means that we can define different levels of dynamic control or dynamic logic based on the route that the user is visiting. So we can support different run times on our project. We can use a node run time, DH run time, which is used on the Edge Network, and GNO for instance depending on the route that the user is visiting. And based on that we can deploy our application or that part of our application in different architectures or different run times. So that's something that we can also have in mind at the moment of creating an application and seeing where we want to deploy it.

So that was a brief introduction to the Edge. I hope that you learned something new. Thank you very much and enjoy the rest of the conference.