Diving Into Server Islands

All right. Hello, everybody. Good to be here in London. It's actually not raining today, so I'm really happy. Who am I? Well, Nathaniel already introduced me. I'm Elion. I'm the Lead Developer Relations currently at React Bricks. So if you want to talk about CMSs, you can find me. Also, I'm freelancing on the side. I'm an Astron maintainer. I used to work in the core team for about a year, focusing on developer experience and documentation and everything. I work with the BGS team, which is a team that organizes conferences in Belgium, Paris, and soon will be in Africa as well. So if you want to be there, you can also come to talk to me or if you want to apply as a speaker or whatever, I can give you some advice.

Cool. Of course, you're not here for me. You're here for Astro content and diving into server islands, and we'll do that for sure. But of course, first let's talk a little bit about Astro since it's kind of necessary to understand where we're coming from and how server islands came to be because it's kind of important.

So Astro, when I talk about Astro and typically like when the core team does, we talk about it as being the web framework for content driven development, not content first, which we used to say, but it's content driven development because it's way, way, way more, especially now. It has some twists though. So think of it as a comparable framework to Next or Nuxt, a meta framework, but it has some quirks that you probably aren't used to.

So it's single file components, just like you would have with something like Vue or Svelte even. Your scripts are at the top. You can use TypeScript. You can use JavaScript as you would normally do. And everything below that is just JSX like you would expect it to behave. It's amazing. We don't use class name. We use class since we're true to the HTML spec. But the weird thing about Astro is that by default, it ships zero kilobytes of JavaScript to the end user. We'll go deeper into this. I'll explain this concept in a more visual way.

So imagine this page, it's a theoretical page of our homepage or website that we are building. All of these components in a typical meta framework, it depends, of course, which one, requires JavaScript to render all of those components. And it actually doesn't really make sense because for instance, that footer there, it has multiple links, whatever. That's all static content. So why are we actually requiring the browser to ship JavaScript, to have JavaScript, to still re-render all of that? That doesn't necessarily make sense. So by default, Astro takes all of that and compiles it down to just HTML and CSS, which is the browser default. And because of that, it's amazing for content-driven websites. It's indexability. For instance, your SEO by default will be amazing. Your accessibility, if you keep track of your areas and alt tags and whatever, it's there by default. So we give you a good tool to start building your app. And that's why I say it's ideal for content-driven websites development, whatever.

Now, of course, we're talking about HTML. It's a little bit weird. We're not in the 80s anymore. We want our website to be interactive. Like, what if I need interactivity? What if I need a button? Like, I want a button on my mobile menu to do something. Well, of course, we have thought of you. And of course, there is a way of using JavaScript in your website. It's called client directives. And client directives, you will be able to control how your website becomes interactive and when those components ship JavaScript to the browser. So it's super interesting. And we have a couple of those. I'll get you like the main ones. Client load for instance, will always ship JavaScript to a button, to whatever component it is. Client idle will always wait on the main browser thread to be free, then start loading in. So that's ideal for like lower, um, lower prioritized content islands, uh, islands of interactivity, whatever. Client media, that's ideal for that button that I was talking about. Imagine you have that button on your page, but you're not seeing it because it's a widescreen. You don't need that mobile button. Well, this one will take in a media query and only execute the JavaScript whenever that media query requirements are met. That's actually really cool. And of course, there is client only, which you can use for instance, if you don't want to have a compiler at all and just ship all the JavaScript that you're writing, um, which isn't an ideal use case, but sometimes necessary when you're working with 3D or something.

So if we then take that theoretical page that I was talking about earlier and we put in those client directives, like for instance, maybe in the header, because we have that mobile button there, we get a page that is actually interactive, but still like, um, is performance wise optimized because everything else, all of those other components is still just HTML. And that's what we call, uh, islands infrastructure or islands architecture. And we'll, we'll talk about server islands in a little bit because this is client islands. This is islands that are coming from the user on their machine. Um, it's a pretty interesting technology. Um, and the cool thing is about Astra that it's actually framework agnostic. So you can use any framework you want because it's all JavaScript. So it doesn't really matter. Um, that's pretty cool.

And because of that, Astra is a very fast, fast framework in general. Of course, this is a little bit of a skewed chart, but all charts are. So, um, okay. Let's, let's talk about like the new things in Astra, because this has been there like since the early days of Astra, Astra 1, Astra 2 and 3, even pre 1, this was like the, the ideal thing. But now we have ship new things and server islands being one of them.

Server islands is a pretty amazing architecture because it takes the same idea of the client interactivity, but it puts it on the server. So, uh, in Next.js you have something called pre partial rendering, partial pre rendering. That's the one. Um, it's basically the same ID or the same answer, but executed in a different way. And we'll, we'll get into that. And also of course, the X Y's it's way better. Um, but that's not hard to fix Next.js.

So, um, think of it as a normal rendered Astra component. I'll show you the code in minutes. Um, it's a normal server-side rendered Astra component, um, but it delays rendering until all the content is available. So it fetches databases, fetches whatever you need. Your page will still render, but it will wait for that one little block of dynamic content that's coming from the server. And then it will show it. And how does that work? Well, we have something called server defer. Um, it's actually coming to PHP now. Well, specifically larval. They also are using a server defer now. So imagine that we have an avatar. It's a very stupid example. I know. And I'll, I'll show you a better one in a second. And we'll defer that to the server because we might need to get some cookies or maybe some authentication to make sure that it's actually loading the right user or whatever. So we are loading from the server, um, the avatar. So what we can do here, and this is why I've chosen this example, it actually shows you that in a server island, you still have access to the cookies. You still have access to the session.

You have access to the authentication because that's all on the server, but still, we're going to pass that to the client in a, in a very efficient way. And how we do that. So this is basically how we get the avatar. So we have a get avatar or whatever, get user avatar, there you see it from the session. Okay. That makes sense. Now, how do we pass that to our client? Well, we get the avatar. We want a fallback. So if you were watching the previous talk, you saw suspense and the fallback. It's the same thing, but it's actually working way, way more efficiently because what happens here, um, we have a fallback slot where we put a generic avatar in, and then once it's loaded, we'll pass it in.

Now, how does that look in a real world example? I imagine something like, um, I don't know, Airbnb. So what happens here, it will reload. Um, you can see there at the top, the, the, the just nine rooms left, that might be an API. That might be database query, maybe a very slow one because it needs to loop over all the rooms, whatever, or maybe a special deal for you. Um, all of that stuff. So what happens there is actually, it will start loading the generic fallback, um, a loading state, if you will. And then it fetches that it knows, I have to fetch my client. It just sends the call and then it will stream in the HTML right into your front end without your user actually noticing what's happening behind screen. Think of it almost as like HTMX on demand inside of Astro without all of the hassle for you as a developer, because the DX is still very much there.

For instance, the lower part as well. For instance, one thing that you can actually really do with this, which is super interesting. You can, um, there is a battery API in Chrome. Who has ever used that? Nobody. Exactly. Imagine you want to book a room and you have 5% on your phone left. You can notify your server, Hey, this guy still has 5% left on his phone. Maybe we should, um, stop the animations and that's a very good use case, but what you can do is as well, Oh, in 10 minutes, this offer expires. And somebody will want to push more like, Oh yeah, it's going to expire in 10 minutes. I have to charge my phone. I have to do this.

I have to do that. I'll buy it now. So for e-commerce purposes, it's a little bit of a nasty trick, but you can do it. Um, I have a talk about that separately as well. Um, but that's for another time.

Um, but one of the great things about server islands and the content layer API, the content layer API is a new thing as well. Um, is that actually it, it allows you to load data in a native way. Um, I don't know if you've ever heard about content collections, which was basically a Markdown well way of working with and offering with Markdown. Um, we opened it up to basically be any kind of content, not just Markdown. So how that works, this is a very simple one. This will give you a collection with all the countries, but the countries are actually coming from an API and it will only get, gets fetched once when you build the website. And then for the rest of it, you have a list of countries. But the thing is that it's queryable. It's not just, um, just a normal, um, whatever list or something it's queryable. And that's pretty amazing because we start to see people hopping onto this new loader API.

For instance, this is Cloudinary, I'm a big Cloudinary fan. I use it for my own website as well. It's pretty amazing. Imagine you can just fetch all of your content from Cloudinary, just like this. You do just define the collection, which is the CLD assets loader, which is Cloudinary assets loader. I want four pictures and they have to come from sample slash food. And now suddenly you can, in a native way, a native Astro way, you can query that collection, use that collection, and display those images in a native, very optimized way. Um, that's actually very, very powerful.

Um, and this was actually one of the first ones where you can do way more because it's open source technology and we're at Astro big fans of open source. Like in a week, we started seeing things pop up like Notion loader. Now you can use your Notion as a CMS, for instance, for your Astro website without actually having to go to the GraphQL API they have, or the REST API, which is huge and very hard to work with. They can just do it like that. It's super easy. Or for instance, um, you're wanting to consume, I don't know why you would do it. Like, um, how is it called again? Um, RSS feeds.

You can just load them in, reuse them, repurpose them. Maybe you have an, a website where you like scroll through articles or whatever. You can just do it with a very simple collection. Um, APIs, um, like Stripe, Stripe. I don't know if you've ever worked with it. It's a pain in the ass to work with. Yeah. So here you can do it like very easily because you just get all your products and suddenly it's in a collection and the collection is queryable. So it's super easy to work with, um, or easier to work with than the default Stripe API, but that's maybe their problem. Um, but yeah, cool.

Um, what if you want to use a CMS and yeah, I was telling you about it earlier. Like it's, it's very hard to use RESTful APIs and blah, blah, blah. No, it's all in a collection there ready for you to use. I really love it.

Um, the next thing that we, we worked on is Astro Actions. Um, server actions probably will tell you something. It's also the same idea, but executed in different and better way, but that's my opinion. Of course, um, Astro Actions allow you to reduce, um, the amount of publicly exposed APIs. Because if you make an API slash whatever form input, um, if you have, you can, you can do a couple of things to secure the API, but what if you just never exposed it in the first place? It's only allowed for internal, uh, usage without having to be public. Well, you can do it with Astro Actions. It's pretty cool.

Um, because you can build type safe, uh, functions that you, um, that you call from the client and run it on the server and then pass in the result. So one of these cases validating form data. Um, Astro is HTML first. So I'm just going to show an HTML, um, solution. Imagine you have that form. So you have the name, email, the name terms. So now you know on the server, if you just submit it by default, it will give you form data, uh, with then, um, an array of email and terms and whatever the value is. Well, what we can do to validate that, we'll just go here. We use Zalt for that.

So you build a Zalt schema. You say, Hey, I accept the form. So it knows this is going to be form data. And then you just do, Hey, I'm going to give you an object, which has an email, which should be an email, um, the terms, which should be a Boolean. And it will automatically for you already validate that data and then execute the handler. If everything is valid, which is pretty powerful, but one of the most awesome things about it is that it's still your application and you have the full flexibility of working with it.

For instance, what you can do is Jack, a simple script tag. You're not using any framework here. Just JavaScript. You just import actions. You import the navigation, which is our client navigation, and then you just submit the form at the event listener. And then at the bottom there, form data is new form data. So you have the form data, then await actions. In this case, a newsletter submission. It's that easy to work with. And it's pretty powerful. I can do with it. Imagine, uh, signup forms and everything. You don't have to struggle anymore. It's super, super easy to implement.

We got to talk about AstraDB because, um, AstraDB over the last year has, um, been a bit of a thing. Um, so AstraDB is this first party API. Um, it used to come with something called Astro, uh, Astro, um, what was our database solution called again? I forgot. Um, see how much I care. Um, Astro database. Um, it's now open for any lib SQL, um, which is a flavor of a SQLite. We, we use Tersa mostly, but how it works is actually pretty powerful. Um, how many of you have worked with Drizzle? Oh, none. It's an ORM. It's an ORM and Astro database actually exposes that ORM and tells you how to use it.

And it's super native. It's a first party one. So in this case, you just have database slash config dot TS, which is just a TypeScript file. And then you just do const comment, define your table, give it the columns that it has the table, uh, and then pass it into the tables. And now suddenly you have a code for his database managed for you. Um, super easy.

And then how to use it while you just do import database and that common thing is to await database dot select, which is like a very easy way of working with your data that comes from this Drizzle from content. Maybe you want to join an author of that comment and then we can just map over it like you would usually do. Um, Astro studio, that was our database thing. Well, it doesn't exist anymore. And if you want to know how and why, well, you can read that there. But in good news, that's what I was telling you about. It's opened up for any lib SQL database now and you just have to pass into variables.

Um, the cool thing about it is when I imagine Astro DB to be is not just any lib SQL, but imagine you could use my SQL or you could use Neon out there, which is Postgres. So you can use any database. Ideally, that would be the solution. We're still working on it. Um, and hopefully it will be possible in the next year, whatever. Of course, that's not everything. Um, I don't know how many of you know, Starlight, Starlight is our documentation. It's well, documentation generator slash website generator. It's basically just like DocuStar is, but DocuStar is of course built on react and everything. Um, it's built on, um, on Astro.

And what the great thing about it is that you can use all of these Astro powerful components like the database, maybe in your documentation, or maybe something like, um, a client Island, because you need that, whatever you can do that in Starlight. Um, the cool thing is that we also added on demand rendering there. And why is that useful? Imagine you have certain pages on your documentation that you want to put behind authentication, but not everything and still get a static output. Well, then this is what you're looking for. Maybe you want to handle documentation from an API. Um, you can do that with on demand rendering. It's pretty cool.

And it's super easy to add, um, just one line of code. The cool thing is also that by the new version, which is 0.28, I think, um, we added better localization. Um, it's super cool on how you can actually do this because as a localities, the translation component, and then you can say, Hey, I need this variable to inject. So count 99. And then suddenly in a different translations, you can have the 99 still be the variable, but translated differently. Um, it's pretty cool. I'm really happy with that.

It's taken a lot of inspiration from Laravel, but the thing is that if people come talk to me, typically about Astro, they asked me, Hey, what's next, where's Astro headed? What are they going to do? So we kind of got to talk about Astro 5.0. Um, Astro 5.0 actually is already out there in beta since, um, whatever, since I think 17th September, somewhere in my slides. Um, but I'm going to tell you a little bit on how and why it breaks and where it breaks, because that's important info for you if you want to use Astro. Uh, the dependencies change.

That's the first thing. If you do a major upgrade, you want to break dependencies because that's where you can actually do it. We're now requiring node 17.1, um, well, 18.17.1, which previously was 18.14 or something. So it shouldn't break too much, but mainly, um, Vite 6.0 beta is the main thing. And why it's still in beta is, well, Astro 5 beta, I mean, it's because Vite is still in beta. Once Vite releases a stable, Astro 5.0 will follow up as being stable as well. So you can already use it there. Uh, or you can already use Astro 5.0 beta today, but it might be a little bit, um, dependent on Vite.

Cool. Rendering modes. Um, as I was telling you, we have the static one, the hybrid one, and then the server one. Well, now we're actually removing full static because it's not needed anymore since hybrid is the default. Um, so you can just use everything static by default and just one page to be a server route. It's pretty cool. Um, so default and just how you change that is just one line of code that you, you switch. That's it. Content collection is what I was telling you about earlier. The markdown solution changed to be completely content layer API. But of course the migration path is easy because you just have to change one line to be a loader instead of default, the content glob, um, which is cool.

We're removing a couple of things that's, that might be actually important. Um, we're removing the first party lit integration because not a lot of people are using it and maintenance is very hard. Um, but of course lit is just web components. So you can still import the script and it's still there. Um, hybrid rendering is being removed. Squoosh image service is removed. We are switching to sharp. Sharp is actually more maintained and a little bit better. Um, shouldn't be a problem. Of course, all the experimental flags are removed because they're stable features now, or at least most of them are. So if there is any more breaking changes, we will publish them on the website. Of course, it's all in documentation. We have a full upgrade guide as well.

So if you're looking for a five that's really good. Um, it's been out since 17th September, which means that we already had a few iterations. We're currently on beta five. I think everything is running great. It's cool. So I'm really happy. Um, you can just upgrade with one command, which is npx.srgs slash upgrade for all of it. If you want the beta, you just add beta at the end and that will work. Cool.

I think that's mostly for me. Maybe if you want to stay updated on Aster or me, you can find me on all socials with add Aelion code, where I tweet a lot about web development in general, but also Astro.build, which is the main landing page of Astro, where there is a couple of things, like for instance, themes, if you want to start from, not start from scratch, whatever. Astro.build slash chat is where our community is. It's a Discord server. We have over 30k members, but it feels like this. It's a lot of fun. Um, it's small and you can approach all the core team members there as well. Cool.

Thank you. I'm Aelion and maybe see you next time. Thank you very much, Aelion.

Let's jump into some of the questions. One of the first ones said, what should React component developers be aware of to ensure their components will run in Astro? Um, for example, is there a React layer or an Astro layer for a design system type thing? Of course, the cool thing about using something like React, in many cases, like people use React in Astro, is that it all is there. I mean, the dependencies you have in React can also have, well, run in Astro. There is no real distinction there because you're still, well, it depends if you're using a client or not. You can just use the same components, like for instance, React 3 Fiber. A lot of people use that. It's totally compatible with Astro, just as long as it's compatible with React, it's compatible with Astro.

Now, we don't have, oh, a question just came in. I just needed to hit refresh. And the next one is why choose, okay. We always get people ask, um, maybe is one better than the other, but then when we talk about what is unique to Astro, that would make someone choose Astro. Yeah, exactly. I think the approach is vastly different. Next is kind of like, it's a full-fledged framework. It's, it's awesome in what it is. Um, it might be a little bit more overhead, but they have opt-out design. I like to call it, whereas they deliver you with all the features, you have access to all the features. Well, Astro does the opposite. You start with the base layer, which is HTML, and then you add a little bit of complexity in your components. And then maybe then at the end you add the image service or maybe then the database it's all opt-in design, which is a little bit easier for me like to onboard other developers, for instance, because it's very clear. Um, also I really like the development experience of Astro. It's very good, like in upgradability, maintainability. I really enjoy it. Um, but yeah, there is still some use cases where I would not recommend Astro for sure. No, for sure.

Um, but yeah, there is still some use cases where I would not recommend Astro for sure. No, for sure. And I think I guess this classic, it depends, but also I think what you talked about at the start of content driven development, like that should be something that if you want to thinking about maybe Astro does. Yeah, exactly. I think that's the main, main point I want to make as well. Yeah, no, for sure.

And, and then the next one, uh, does Astro have a concept of context similar to React? Yeah. Um, well, yes and no. Um, it depends as it always does, of course. Um, no, in the sense that, um, your islands are islands with a reason, like they're islands of interactivity that cannot really communicate to each other. Of course you can, and there, there is a couple of ways, like you can do state management in between both, but it's not really meant to be. Probably if you're looking at context, you're either not doing something right in, in Astro, I mean, or you shouldn't be looking at Astro for the solution. But of course, if you really want to, you can run a full SPA inside of one Astro page so that it is possible to use the context across pages. Yeah. No. Awesome.

And so this is kind of, we talked about how, what might make you choose Astro. Yeah. And then where are some things where you're like, if you want to build this, I wouldn't recommend getting started with Astro just so that people can pick the right tool. Yeah. For me, it's always like the, it's a content driven thing all over again. Like if you're building a website that has to be indexable, that has to be flexible in a sense. You, you want a lot of flexibility. Like personal websites, it's an amazing feat, like an amazing use case for Astro or blogs, whatever, because the author experience and everything and the maintainability, but imagine that you're building dashboards, authentication services, multiple APIs, then you might not look at Astro because rendering all of it, if you're rendering everything in a client island anyways, or a big client component, whatever, then probably Astro might not be the ideal fit for you. It doesn't mean that you cannot do it. It just means that you might not take advantage of Astro's powerful sites or features. I mean, I've had the pleasure of watching you speak about Astro and it's really interesting that this question specifically comes in and you've been with, you've worked in the Astro ecosystem, shall I say, for a while. Yeah. What, have people begun finding like Astro for what they need or is it still kind of people not sure what it is? Yeah. It's very much changed.

Actually, like when I started in Astro, it was version 0.14. We're launching 5.0 now, so we're four majors ahead of already. The amount of features that we added is insane. It went really fast. And the thing is that when we started, like Astro was nothing more than really a website, static website generator. And I would only advise to people to use it for like blogs or RSS feeds and that stuff. Personal websites in general. But now like you can build really powerful applications. We have database in there. We have image optimizing, all of that stuff.

So all of it really changed. And the good thing is that over time we became like a competitor to other frameworks and people started like comparing Astro with. And that's good like for visibility, but not necessarily for like the use case, because Astro is not really trying to fight any framework. If anything, we try to push the web towards better standards, which is also succeeding by the way. But like, for instance, one good use case or example of that is when we shipped Vue Transitions. Suddenly, like in the three weeks that we shipped it, suddenly all the other frameworks started adopting it too. And now we have it like being a standard there in Chrome. So I think Astro is a friendly neighbor out there in the web space. Friendly neighbor.

And with that, we are running out of time. But if you do have a question, you can always come and chat to him. And where can people find you online? At Alien Codes, everywhere, like on every platform. I also have, I think, if you go to my website, there is a slash links and then you can see all of my social media, all of my whatever. All the links you might need. Awesome. Make sure you rate the talk and give him a round of applause. Thank you.