Edge tooling — What, when, and where to do the work of delivering your site.

Well, thanks so much for having me at lazy load.

I'm delighted to be able to be a part of the event and to contribute a talk.

And here I am to talk about edge tooling.

What, when and where to do the work of delivering your site?

First of all, Hello to you, people of the future.

Here I am talking to you from the, the past, the very distant past, the very recent past, rather, but the past, nonetheless, this talk was made in advance.

And you know, why am I calling that out?

Hopefully that'll become clear later on, but this is a video that I've made for you.

So it was ready to watch when you came to watch it.

I prepared it just a little in advance.

Also, I made it for all of you, which is not to say I made it for each of you.

There's a distinct difference.

I'd love to have made an individual video for each and every one of you, but I made one video.

That's being played to all of you.

And again, why am I calling that out?

Hopefully that will become clear as we get into it.

But ultimately.

I felt that was best given the format of the day, the way that giving a conference talk works in this kind of hybrid mode I felt it was best to make one video ahead of time and make sure that that was available for you as as when you came to consume it.

How are you consuming it?

Well, of course you're using my very favorite application that exists.

It's a Web browser and these are magical applications that open a window to all kinds of content.

They really have come a long way.

What a lot of progress we've had since the first browsers through to the browser that you are using now.

We've had so many advancements in the, the browsers and the technology that's used to deliver content and and, and applications around the world over the Web.

And.

With that of course brings lots of choices with lots of possible ways that we could deliver something.

So the choice of how is super important.

And that's what I really want to talk about today.

You know, what's the best, what is the best platform?

What is the best set of tools?

What's the best architecture, what's the approach and how on earth do I choose?

As you heard at the very start.

My name is Phil hawksworth.

My pronouns are he/him and I'm a director of developer experience at Netlify.

And really, I think we should just keep, keep rolling into it because there may be questions along the way, and that's great.

Although this talk comes from the recent past, I'm very much in the present.

I'm there in the chat.

We're looking forward to any questions, comments, discussions that happen along the way, hit me up in the chat.

Let's let's talk about as we go.

Of course, otherwise you can contact me afterwards as well on Twitter.

I'm @philhawksworth on Twitter.

Love to talk about this stuff.

So again, hit me with questions should you wish.

What are we gonna be talking about?

Well, as I mentioned, the work of delivering your site, when to do it where to do it.

And also how to do it.

And we'll, we'll have a very whirlwind tour along the way.

I want to talk about all of those things in 10 minutes, or rather a little less than 10 minutes now that I've had that bit of preamble and context setting.

So we should not hang about, we should get right into it.

What work?

What are we talking about when we say doing the work of delivering your site?

As we know building for the Web involves a lot of disciplines and a lot of work.

So what are we talking about when we say doing the work of delivering a site?

Well, in this context, what I'm describing is the work of generating the view that your users see.

So we might think about that as rendering or generating the views, whatever terminology we want to think about.

It's about generating those assets that the, the the users are gonna see in their browsers.

So let's get into it.

When do we do the work to develop the sites?

Well, let's, let's think about how we've evolved over time, 'cause once upon a time we had this lovely, simple model where we would generate some things maybe that was by hand cranking HTML, or using some other tooling to generate things, to build some, build some assets and we'd put those on a Web server, so that when the users came along, they were ready to go.

And so we had this, this decoupling there of doing some of the work in advance and then some of the work was being done on demand.

So the creation of the assets was done advance and then the delivering of the via Web server was done when that was requested.

A little bit later, on the, on the Web, we started to see you know capabilities and of the tooling to evolve a little bit and the demands of the users to evolve a little bit.

And we started to, to do things a little bit more dynamically on demand.

So we might have a Web server or an application server that would both render, generate the views that we were going to return to the user and serve them, but it would be doing all of that together when it was requested by the users.

So in other words, this was all happening on demand.

We weren't doing so much in advance, we were responding to the requests and for each request we would generate the response and serve it.

Now a little bit more recently lately we've seen the resurgence of this kind of architecture where we're kind of returning to this idea of doing things in advance, but things have changed because now we've got this developer tooling and these resources and services that we can now use to automate so much of the work of generating our views and getting them deployed to a hosting environment.

And these days, things like global content delivery networks are way more available to us because of the types of services that exist.

So streamline this, streamline this effort.

So now we can be generating and deploying things in an automated fashion in advance so that they're ready to serve in the simplest possible way to the users when they come to request it.

However, we're moving beyond that again.

And so how can we retain this notion of doing some of the things in advance and some things on demand, but still try and keep this kind of automation, this security that we have from this kind of pipeline and workflow?

Well, we're starting to see now that some of our resources and some of our views are pre-generated and served from a global CDN, whereas others, we can start to compute at the edge, rather than at a build server, but at the edge.

So this is, this is when things are happening on request, either things are being statically generated ahead of time or some things we can do dynamically and serve those directly.

And again, we've got this decoupling of some things happening in advance and some things happening on demand.

I'm a big fan of doing as possible in advance to try and keep the mistakes away from the users keeps the, keep the error prone moments away from the users so that we can have mistakes happen in our domain.

Like with this video this might not be the first take.

That's fine.

You don't get to see that.

You get to see this version, my mistakes don't leave the house in the same way.

Pre-generating things can, can be an advantage there.

But, we're not always able to pre-generate everything.

We can't always do everything in advance.

Some content needs to happen a little bit more dynamically.

We might be thinking about serving some content based on the location of our, our users, or we might be personalizing things to a specific user or doing things based on the time that they access access our sites.

So not everything can always be done in advance.

So that means we have to start thinking, not just about when we do it, but also to do a good job of this, where we perform some of the work of delivering our site.

So where do we do that?

Well, once again, we've got a model that perhaps will feel nice and familiar to us where we've got a client and a server notionally, and the work is done on the server, very often.

So again, we are generating the response on some kind of logic and some application on a server that's returned to the client.

More recently, we're starting to see trends towards things like single page applications or very client intensive applications where the work is done in the browser, on the client, where we might be rendering templates or updating views in the client.

So that moves the work from one place to another.

Or indeed we might be doing it in both places.

Both of these things might be true.

We've got the opportunity to do some of the work at the server and some of the work at the client of, deciding what's going to be returned.

What's gonna be rendered, what's gonna be shown to the user.

I'm a fan of moving things out of the server, wherever possible.

So moving things into a build server instead, so that the, the work is done in environments that is not part of the request chain, but on an environment that I've got complete control over, whether that's a, a local development environment or a, a CI/CD environment that's running a build so that then we could generate assets that go to the server ready for when they're requested.

And if we do that, it means that we can simplify that server, simplify the part of the, of the infrastructure, which is responding to all of these requests and replace a, a server or a set of servers with a CDN which is optimized purely for delivering the assets that we've generated ahead of time and delivering those to the client.

Now, we still might be doing work on the client in addition to in the, in the build server that's entirely possible.

And we might now want to think about, well, we've talked about having things that are more dynamic and specific to each user, this is where things get really exciting, I think right now, because now we're starting to see the emergence of edge compute and edge functions where we can do work on demand, but without it being in a server that we have to maintain.

I'm a big advocate for trying to do work in as few places as possible.

You know, the fewer places we do the work the better because we have fewer pieces of infrastructure that we have to maintain and have to have to worry about things failing.

So the work can happen in all these places, but we, we can pick and choose where it should happen.

I feel like the more predictable the environment where work happens, the better.

So if we look at the places here where work might be happening the client in some edge compute where it's a serverless function or in the build infrastructure, we've got different types of predictability there.

And our build environment is very, very predictable.

We've got complete control over that.

Likewise in edge computes, if in a serverless function environment, it's a very known quantity.

That's not going to change so that we've got a very predictable and knowable environment for where work is being executed.

On the client, of course while this is getting much more powerful, it's much more varied, also.

You know, we have to think about the different browsers that exist.

The different devices that our users might be accessing our sites from, where code is being executed in the runtime, in their devices.

So each one of these places brings different possibilities, but it also brings different risks and considerations.

So we need to think about all of those things.

Which brings me to, how-how do we do the work of delivering the site?

Well, as you've seen we've, we've got to have an understanding of when and where it's possible to do the site, do the work of the site, but there's something else that informs the, how there's this blank and what is that blank?

What is that blank, you know, understanding when we're and what we're creating really informs the approach that we have to take.

And of course, that leads me to this phrase that is a bit of a favorite for everyone.

"It depends".

Now it depends is a really important answer because we've gotta consider all of these things when we're thinking about the architecture we're going to choose.

But our decision is really informed by all of those things.

We're not just taking a guess, taking a punt, you know, the, the, the, what we're making and the possibilities that we've got for how we deliver it really informs the way we might approach it.

Modern Web development tooling is wonderful for this.

This might be a bit of a controversial point of view.

I know that a lot of people are thinking it's just got too complex now, and there's, there's too much of an on-ramp before we can start building things for the Web, but we don't have to use every tool at our disposal.

We've got got the option of using a wide variety of things.

And as a result, we've got this possibility where we can choose when the code is being executed in all of these different places that I just highlighted.

We've got the, the control over choosing where the code is executed.

What part of infrastructure, and thankfully, to, because of the types of tools and services we're seeing emerge, we've got a chance to simplify our code by leveraging unified workflows and the capabilities of lots of the modern tooling that exists.

Netlify is one example, and of course the, the the speakers around the conference are from other companies that also offer this kind of this kind of capability.

And it's a really exciting time for Web development as a result.

Serverless run times are exploding now we've seen so many opportunities to create serverless run times to add to our simplified hosting infrastructure.

And we want that without sacrificing the current workflows and benefits we've seen by moving to a, like a decoupled architecture and without sacrificing is super important, which is why I'm particularly excited about the emergence of edge functions and edge computes from places such as Netlify, which really push the envelope, without pushing the complexity of the hosting infrastructure that exists beneath.

There are so many exciting choices in this realm and we'll hear about lots of those across the course of the Lazy Load event.

And I'd say that whatever you choose really think about when and where your code executes and what capabilities you have to decide on those things.

We need to think about, you know, whichever we choose, think about the opportunities to reduce complexity, move away from servers that we have to understand a lot about and move to a much more discrete, knowable, small surface areas, such as serverless functions edge compute and the like.

And whatever we choose, we need to think about the confidence and the velocity that this brings to our workflow.

Finally, we need to think about the experiences we bring to all of the users as a result, remember that when we're using these tools and choosing these tools, it's great to be able to produce more confidently, to be able to produce sites with more velocity, but ultimately we're trying to produce something that's great for the users-and that's, that is really key.

So where can we learn more after this very, very brief appetite.whetter, thinking about the tools that are available?

Well, all of the talks at this event are gonna be providing all kinds of inspiration and ideas about tools that we could use.

I would call out, of course, since I work at Netlify some of the things that are arriving at Netlify, we already have a number of different types of serverless functions and serverless run times that we can bring to bear and the latest of which are edge functions which allow you to do such things as transform, transforming HTTP responses.

Doing things on demand at the edge with very low latency.

And you'll hear lots of talks around this event of similar tools and similar approaches, I think are really exciting for the way we build for the Web.

So, to learn more you can go to netlify.com/products to get right into learning about edge functions there and get into a hello world right through to building an application.

And likewise, you can read about it doc.netlify.com.

I'll be around in the chat as I mentioned and around at the event.

So so please do let me know your thoughts, your questions about some of these things.

I'd love to see what you are all gonna build with this exciting new set of tools that we can use in a really thoughtful way.

Thanks for your time, enjoy the event