Island Architecture

[00:00:00]
>> Steve Kinney: I thought about dividing this into two parts of one are like, oh, the architectures you might find, right? All the places you'll go, and then kind of the second act being all of the unglamorous stuff you need to do to keep your codebase healthy over a long period of time. So, you know, we'll talk about stuff like CI/CD pipelines and, you know, you might think, why would I ever need to write a custom ESLint rule?

[00:00:28]
I think if you were trying to deprecate a pattern, right, and trying to guide people into not using deprecated packages and stuff along those lines, that's super useful. I do think, you know, we're talking a little bit about AI coding tools, right? Like, if, you know, especially for a lot of times, those tools will look at your codebase and use patterns to decide what to do next. So if you're trying to deprecate stuff, it becomes a game of whack-a-mole.

[00:00:58]
And so we're all going to have a rich conversation coming up about, yeah, observability, CI/CD, linting, design system governance, but before we kind of go into that just to kind of keep the theme, I wanted to do some of the maybe, when less popular doesn't feel right, newer, right, maybe like, or still kind of a little more esoteric architectures that you might see in the world. You know, for you to either have them be familiar, they might solve a particular problem for you, but they're kind of just kind of do a high level of a few of those to kind of fill in that kind of contextual framework and then we'll kind of get into the nitty gritty of keeping an existing codebase alive, because even when we think about microfrontends versus monorepos, it's not necessarily always a, it is an architecture, right, but it's not a fundamental architecture that you are locked into forever.

[00:02:05]
You could tomorrow take all of your various different repositories, you know, copy them into one folder and make them one repo, you know what I mean? You could do it. The CI/CD pipelines, it's not lost on me that there's more to it than that. But you could do all those things. There are a few other approaches that are not one size fits all, right? And so one of the newer ones that you might have heard about is this idea of the islands architecture, which is in many cases synonymous with a framework called Astro.

[00:02:48]
And it seems very exotic, possibly because of the name. But it's not really. In this case, but I think it's worth talking about. I will, I probably have this on the slide, but I'll start with the caveat and then just repeat it when the slide comes that I would say that it is, I alluded to this earlier, there's not always a one size fits all for everything, which is the needs of a content site, right?

[00:03:14]
And the needs of maybe what is like, you know, you think about like looking at maybe, yeah, like the New York Times versus Figma, right, when it's running in the browser. Those are two, they're both running in your browser, but there's two very different experiences. Your patience for that Reddit post you probably shouldn't have been reading when you had other stuff to do while dinner is ready and you've been called four times at this point, right?

[00:03:43]
That page needs to load faster. You're going to start actually doing the things you said you were going to do 10 minutes ago, right? You're probably willing to wait a few more seconds for Figma to load because you have work to do, right? And what an app we live in versus a different content site. So for some of the stuff, it's stuff where it's maybe not for everyone. That's totally fine. You should not feel any pressure that you have to do these things, despite what you might hear on Twitter.

[00:04:11]
So one of them is the islands architecture, because for some people this is going to be incredibly important and effectively, though it is both the tooling makes it incredibly modern and the concepts, if you've been doing this for a while, are going to seem familiar, but I think I alluded to this before, like everyone was like, I'm not using Rails anymore. I'm going to have small Node.js services.

[00:04:42]
And everyone did that for a little bit in 2013. It was very adorable. And now you look at Next.js and SvelteKit and even honestly modern day Rails, and you're like, oh, it's come back, right? And with better tooling, better everything, right? I used to be a Rails developer, trust me, I understand the difference. But the idea of the islands architecture is maybe you have a static site. There is this talk slash slideshow slash blog post by Addy Osmani from, I don't know, probably a decade ago, maybe seven years ago, but it stands true, which is the real cost of JavaScript, right?

[00:05:33]
And the point is, if you send, you know, 500K of an image and you send 500K of JavaScript, which one of those is worse? It's not a trick question, it's JavaScript, right? Because the difference is JavaScript, despite what we think, is a compiled language. You're not the one compiling it, the browser compiles it, V8 compiles it, so on and so forth. It needs to be interpreted. And so every bit of JavaScript that we ship comes at a cost.

[00:06:04]
And when he was popularizing that, it was during the golden era of the single page application where the HTML you were sending over the wire was like a body tag, a head tag, and a script tag that then loaded like three megabytes of the entire application, right? When he made that point, it was a time where that point needed to be made. And since then we've seen server-side rendering and some other, you know, many other approaches like Next will do this, SvelteKit will do it out of the box.

[00:06:41]
Astro is another way to kind of think about it. And it is for a certain kind of site, right? Again, if you think about maybe a content site, honestly, even this example where it's like a storefront, right, a lot of that is prose and images, right? We didn't need to send a bunch of JavaScript to then assemble a bunch of HTML, right? But then there are these, a lot of cases, a little bunch of islands of interactivity, right?

[00:07:07]
And this is not totally dissimilar from what we're talking about with the microfrontends in the beginning, which is kind of why I bring it up, where it's like maybe you had that team in charge of this one piece and this team in charge of another piece. And so it's the concept that you might ship a static HTML page with the CSS and everything, and then as needed, load the JavaScript for a particular part to make that piece interactive, right?

[00:07:40]
And, you know, this is not a workshop on Astro. Astro is very cool. At least on a weekend you should play around with Astro. Astro allows you to do some of the things that we joke about, but it is actually useful, like, you know, with these various islands, each one could technically be a different framework, right? Like you can do the different frameworks yourself right now. Like if you think about when you use React, you're giving it a div that it's rendering stuff into.

[00:08:13]
Usually that is like ID root, right, which is the only tag in the body, but it could have just been one piece of the application, right? And, you know, theoretically you could have React rendering to that one div over there, Svelte rendering over there, Vue rendering down there as well. There's nothing stopping you from doing that other than that most of us just don't need to. But it is a powerful concept.

[00:08:41]
Astro kind of lets you wire that all up and supports all the frameworks out of the box. But it's not the only islands architecture either. The team at Deno has one called Fresh, right, and it's not dissimilar from Next where you write these React components in this folder structure and, I mean, Next does this too with additions to like getStaticProps versus any of these, where there's like fundamentally what gets shipped first is it may look like JSX but we're going to produce some HTML, right?

[00:09:12]
And it will assemble all that HTML and then as needed, load in the interactive parts. This is pseudocode, this is not Astro, this is not Fresh, this is nothing, this is vanilla JavaScript to help illustrate an idea, right? We'll go back into some of the other slides in a second, but the idea that you could just, you know, you'd have the various parts of the page and kind of render them, you know, have the statically rendered ones and replace them is a thing that you can still apply to the team autonomy, right?

[00:09:43]
There's nothing stopping you because these things can sew up that page in a way that might seem infeasible with most tooling today, right? And I've mentioned this not because I'm like, you should use Astro tomorrow, maybe you should. The point is, whatever the constraints that you think you have, these principles apply regardless, right? Could you take inspiration from a bunch of these things like, well, I like this idea of maybe the monorepo or I like the separate repos because I like the idea of individual deployment and putting them in runtime, but maybe we have an intermediary server just taking all of those federated tools at the edge, right, because you have a lot of Vercel and Lambda at Edge, you have the ability where you could wire together that page.

[00:10:29]
You could do all that importing at the CDN level, wire together a page and send it over, right? Like, whatever you think your constraints are, you can pick and choose from these approaches and ideas, and maybe there's tooling, maybe you might have to build it yourself, but the idea of, whatever you think the problem is, I would argue that there are solutions, maybe not all together in a perfect bundle for you in this workshop, but a little bit from there, a little bit from there.

[00:10:59]
And so, I think most people will not be able to just migrate. I'm sure the team will tell you you can do it in a weekend, but we all know politics and other stuff like that. But it's worth playing around with to kind of get a sense of it as well. And so, you know, because if you're still defining it very much like you might just have the add to cart section, right, and that can render a static HTML and it's part of a larger tapestry, right, but you can have this separation and also have some of the server-side pieces as well.

[00:11:36]
And each one of them, it's not like, oh we have to load all of the JavaScript, right? Like each one then can kind of fetch it independently and we can parallelize it and we're not waiting for the entire bundle, so on and so forth. And the idea is to make it as light as possible. And so yeah, like you ship the HTML first, you only hydrate the real interactive regions, and you optionally try to defer stuff until you need it like you can wait until that part shows up onto the page.

[00:12:10]
You can figure out the code splitting part. Most of it, all these things are built using usually the same set of tools, right? Like SvelteKit, for instance, is built on top of Vite with a Vite plugin effectively and some other scripts around that. Next is, oh my God, is it Turbopack? Vercel has their own play on webpack that is lightning fast, right? But it's effectively a webpack-like thing. Those are all tools you have access to as well.

[00:12:38]
Now, yeah, go to the full framework with something like Next or Astro, or think about the level of abstraction, but now if you can't totally opt into that because it's a lot of times a refactor, there are probably solutions. We saw that a little bit of build tooling, for instance, can dramatically speed up your CI/CD process, right? All of these are most of those problems where we go, well, it has to be this way because it would challenge you that it probably doesn't.