Astro DB with Ben Holmes
===

[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it free at LogRocket. com. I'm Chris, and today we have Ben Holmes, software developer at Astro, here to talk about AstroDB.

Welcome to the show, Ben.

Hey, yeah, is this like the third time we've talked about Astro on this show? It feels every major milestone we've got some coverage, which is awesome.

I've been here. Yeah. I think this is probably my second time with you, I think specifically, but I think you've been on here quite a bit, but let's dive into it. Yeah, I know you are doing a lot and I'm actually pretty stoked to talk about this with you. Astro DB. Honestly, I did not see this coming to be honest.

So can you tell us like what exactly inspired. AstroDB.

Yeah, it is a funny sell because you would think Astro's the content site framework. So they're going to go build, I don't know, cloud hosting or something. It is the Astro [00:01:00] technology company after all, but no, we, Did a lot of brainstorming to figure out what is the primitive thing that we can build on top of to build the vision for Astro that we have.

And from the beginning, we've tried to target WordPress's model of you have this area where you can store all of your content, data, et cetera, and pull it into a site that you can build with modern tools. No more PHP. Now it's JavaScript flavored PHP, if you want to look at it that way. SRDB is that first primitive, where it's the lowest level of storing things is, of course, a database.

And we wanted to choose something that is very accessible, something that can tie us to a nice free tier, which was SQLite, which is cheap and fast to host, of course. And we slowly built out an experience from there with an online portal to view all of your stuff, and also really dialed in dev server.

experiences, because when you own the framework and you own the [00:02:00] database, you can do a lot more stuff than if it's just a, separate tool from the framework.

Gotcha. So like, how does this ~like ~address ~like ~common challenges faced by astro devs? Were they asking for this? Were they hitting ~like ~potentially scaling problems with the amount of content they were having on their site? What was happening there?

Yeah. There is some scaling. And especially when we introduced content collections, which was like start of last year, that was a really big step on a lot of people like get based content. We have a lot of Gatsby users and others that want to have that, dialed in MBX experience. We built a lot around that, but you hit a fundamental wall at some point where you're just rebuilding all the SQL primitives okay, we figured out how to fetch a bucket of markdown.

Now, how would you reference an author from a post? Let's implement references. And it was at an offsite where Erica, another member of the team came up and said, you're re implementing SQL light, right? Is that what we're doing? And it's yes, and then we started thinking~ yeah, ~what if people ask for sorting?

What did [00:03:00] people ask for? Just fetching certain parts of frontmatter and expecting queries to be faster. When you're doing everything with JavaScript objects, you just hit a ceiling of how fast a JS object can be, instead of getting down to the raw data. It was born out of that, and then we saw a lot of other use cases what if you want your content to be stored, Separately from the website so you can have deploy previews so you can have people come in and edit things and also Being able to write data from runtime because Astro has server rendering more and more people are playing with Authentication libraries like Lucia and they need somewhere to store data for that So it became this it's called an Eigen solution.

It's this buzz term that's been floating around the Astro team a lot. There's a tech article about it. I could probably go find, but it's a solution that solves a lot of problems at once and is primitive enough that you can kind of mold it into whatever you want. Like you can mold it into an authentication plugin.

You can mold it into a solution for get based content. So yeah, we were [00:04:00] like, databases are primitives. They've been around forever and let's use that as the path forward to help you scale content and writable stuff.

Gotcha. So when I hear AstroDB or when I did hear about it, I was like, oh, I guess it's like a planet scale competitor or another one of those. But it seems like AstroDB is ~You ~very like uniquely tailored for the Astro like ecosystem. So can you go in depth, like how those go hand in hand?

Yeah, exactly. And I feel like there's a lot more in the vision than what we've launched with so far. The thing we've launched with is definitely like the dialed in. Dev and production experience where normally if you wanted to set up, a SQLite database that seeds all the data when you start your dev server and has a place to query it, something like Drizzle or Prisma, you need to go find three related libraries, cobble them together, and figure out how it integrates into whatever bundler your framework uses.

And that's a lot of manual setup. People weirdly haven't combined those three different things to build one pluggable [00:05:00] tool. So Astro DB right now is taking a SQLite primitive, which is, I should be saying a lib SQL because it's a distributable version of SQLite. It's a newer term for sure, but it's to give some context, it's an open source version of SQLite.

That was forked off in order to add more and more features because believe it or not SQLite is actually a read only source It's not super open to contribution So now there's this fork that exists to take SQLite to new places like replicating SQLite databases in different regions So if you deploy to multiple regions, you can make reads even faster.

So we took that technology. We bolted it into drizzle, which is a really nice layer to query stuff from JavaScript. And then we wrapped it all with our dev server handling. So you get really cool pieces. Like you can edit a seed file and it will just hot module reload all the pages that are looking [00:06:00] at the data So you don't even have to restart anything.

There's no manual setup It just magically reloads the dev server with the new data and you don't have to do anything so it's really nice how we set it up with VEET specifically and ~Yeah, ~a lot of people are already asking can I use this outside of Astro and our goal right now is yep We want to make you jealous We want you to look over and see, wow, if I use Astro, I can get this really nice data layer.

So it's definitely dialed into what Astro has.

Yeah, I think that's pretty sweet. Cause I know if I stamp a new app, I have to go through the ceremony of either setting up the DB myself or going through with some provider and going through the docs and sending it up where it sounds like with Astro, like it just makes it. That easy.

I think like your site was like, get running in like 30 seconds. And I tried and I was like, Oh wow, this is like incredibly fast. And just like pretty much abstracts all the stuff I don't necessarily care about. I just get up and running. So I think that's like super cool. But in terms of like features, can you explain like how Astro DB stands out?

Cause [00:07:00] right now, nowadays there's like a million choices, right?

Yeah, so definitely standing out in dev experience, setting everything up for the first time, and also trying to stand out in the database viewing side of things. Because right now, when you go with a database provider, like PlanetScale, like Supabase, when you go online, you're gonna get a visual table viewer.

And you can manage all of your tables, and click into references and look at those. But, that's kind of everything. All you get is just a view of your data, but we looking at, the WordPress model, people who use things in a more content focused way, they might want nicer views on top of the database, like instead of looking at a table with a bunch of blog posts.

You could look at a rich text editor that pulls up the blog post and does an auto join on an author's table and pulls that in. So all of the complexities of, I need to spread out all these SQLite tables, we're imagining what we're [00:08:00] calling studio apps, where you could have an integration for a blog that stands up a blog table, an author table, a category table, and then gives you a viewer that Pulls all of those together.

So you get this really nice place to both manage your content and then also query it from your app. So that's the story that we're really trying to grow into is figuring out some of those common use cases like building a form or building a blog and building first party solutions to those that are really primitive.

And then, seeing how that could be a wider ecosystem piece. So that's really where I think AstroDB is going to come into its own and we can see a lot of growth, but today it's definitely that dev experience choosing the right tools for the job lib SQL, and we manage all of the distribution for you.

Similar to Torso, if people have ever used that tool where it distributes to a bunch of regions around the world. We do a similar thing, letting you choose a region and then persist it in a database.

[00:09:00] Awesome. Everything you sound, everything you've mentioned sounds like amazing but what's like the migration story for, if I have an existing Astro. Site. How do I integrate that in there? And then if I am just coming into the Astro ecosystem, how does that look with integrating with AstroDB?

Yeah. So if you have an existing project, we made it an integration, which is Asher's way of just adding a lot of plugins to the dev server and production builds, so you just run Astro add DB and it creates the config file, creates a seed file, and you can just write data. ~Yeah. ~And suddenly you have this thing that you can query.

So that really is all you have to do. And if you wanted to be an integration author yourself, like you want to have recent example, an authentication integration. That's a lot of syllables. Lucia is a really popular library that just handles OAuth for ~Google, or I was about to say Facebook, but I don't know if anyone uses Facebook login anymore.~

Google GitHub for sure, Twitter, there's a list of 20 providers that it has. Even has OSU, which is the Rhythm Game. You can [00:10:00] authenticate with that,

That's so random.

it's wild. But yeah, it gives you all of those options with buttons to log in and there's already a community integration that takes Lucia and writes all of your users to an AstroDB table.

So now it manages the session cookie. It gives you login options, and then you can query for the user by just saying, query the user table. So you own it. It feels really dialed in. And as an integration author, we already have docs that show how you can stand up tables for the user or how you can precede data for the user so that they get something that's ready to go.

It's awesome. So I know we've been talking about LibSQL, which I believe is maintained by Terso. It's like a fork of SQLite.

Yep.

How does Astro leverage LibSQL to give you ~like that ~lightweight and ~like ~scale that you need?

Yeah. And it's actually dev and scaling. So before this, we were trying a bunch of other SQLite tools, just like better SQLite, [00:11:00] which is. The standard JavaScript library used to just talk to a table. And it has some issues because it's using like a C plus binary. If you're on windows, you might run into installation problems, which we didn't love, and if you're using an online editor, like stack blitz, it also doesn't load.

You need like a web assembly version of it. So there's all these things to consider just trying to have a SQLite tool that works in dev. And libsql just happens to solve all of those for us. So there's no weird binary issues. It installs everywhere pretty easily. And in stack blitz it totally works so we can have these templates and issue reproductions Which we really rely on that are just in a portal So libsql definitely helped us just make sure it's easy to set up and for scaling It ties into the torso hosting service, but you could technically ~You ~Set environment variables and hack around it.

But we rely on Terso for our infra. So whenever you deploy a database, we deploy to a region [00:12:00] and it takes your SQLite database and puts it in that region. And soon we'll also add replication where it'll replicate to a bunch of regions around the world. So that reads are even faster. So the layer that it puts on top is being able to request from a database.

Just using an HTTP connection. So it's like pinging an API. You're just pinging a database and it gives stuff back. PlantScale is a super similar model. And Torso does the same thing for just a SQLite file.

Gotcha. So ~I know we're, ~I know we're mentioning like words like Terso and then The product itself says AstroDB and in this age of SaaS, I feel like people are always worried about lock in or is everything stuck with you? Or is there a migration path off? Can you go into this, how zero lock in works and how it differs from like other database solutions?

Yeah. And there's always going to be a degree of you're tying into the Astro ecosystem. It will be a nice experience when you do that. But because it's a SQLite file, it is super easy to, [00:13:00] we literally have a button in your settings to just export file. And you just export your old database.

Here it is. And you could go take that and just, attach it to a Drizzle instance, or put it in your Next. js app. I don't know. So you're never really locked into the database storage piece, because there's no fancy servers or anything going on. You can just take that SQLite file and embed it some other way.

Because it's file based, it's super easy to just let you go try something else.

Yeah, ~I think that's also, ~I remember when I was, Going ~through the ~through the docs. I saw like export as SQL or export as like CSV or something like that. So it's like a quick eject button, essentially, which is pretty nice. I think that's like something I feel like a lot of customers or users need that reassurance because what happens if God forbid something happens with the product and he's like, where's my data?

I need it back. That's always like a concern for everybody.

And we were trying to be, ~yeah, er, ~to that point, we were trying to be really careful with framing, because right up until launch, we were going to call them collections in fields and other things, and then we realized, If we use any word that's not [00:14:00] SQLite, you might worry that it's some proprietary storage.

Because exporting from Firebase, a mess, you can't take that anywhere. You've got your data, but it's in this weird document format, and you don't know what to do with it. And I've seen some other tools like that, where it's data storage, but better. And, SQL's pretty good. We'll put stuff on top of it, to make it look nice.

Like a viewer to, Bring tables together, but it's still just tables and you can do what you want with those once you query yourself

Yeah, exactly. I think that's super awesome. So let's talk about the visual data viewers. I think this is like a very popular thing amongst ~like ~people, especially with people getting into ~like ~databases and stuff. So how does the inclusion of these visual data ~views, ~viewers enhance the user experience when working with the data?

Yeah, and so far it's definitely Just ongoing seeing how we want to make it nice Because we have the studio app right now You can go in there and look at all of your databases and deployment regions And we do have some little [00:15:00] abstractions on top for common storage needs. Like instead of having a date where you have to stringify it to ISO, and then you go on your online viewer and you have to type out an ISO string or something, that's weird.

But we figured out Drizzle has this really nice convention called Custom Types. Where you can just wrap around a SQLite layer and it'll just convert it to another format whenever you query. So we added a date type where it will take in a date object, flatten it to a ISO string so that it's actually storable.

And then when you query it, it gets it back as a date. So that way you can, use all the internationalization APIs in JavaScript. To type out the date however you want, format it when it queries out of the database. And also when you go on the online viewer, you get a date picker, as you probably should.

And there's a lot more that can be done on top of that. People have already been asking about Zod validation and other weirdness. And the tools are there. The primitives are there. [00:16:00] So I think just making the friendly database is what I've really wanted to see. Something that's your mom's air table where you have all of those drop downs and pickers.

It feels like that should be accessible, and Drizzle is definitely a big part of that.

That's awesome. So let's get a little bit more. In the technical details. And I'm sure many people are interested. Could you explain like how developers actually define databases in AstroDB is there an element of like type safety, like what's going on there?

Yeah, and yes, there's definitely type safety. At this point it's just a given. If you launch with type any, you're just ignored. Or you're in the Ruby on Rails crowd, I don't know. But ~yeah, ~when you set it up, ~it does ~it gives you a config file and a seed file to set everything up.

So when you get going, you can just create a table and create your table schema inside of a TypeScript file. So the same way it works with, I think Keasley and Drizzle, they both do this. Maybe Keasley ties into Prisma or something weird, but I know in [00:17:00] Drizzle, you can just create a TypeScript object. And then say, here's all the table columns.

It's going to be a primary key. And that's like a TypeScript function that tells me this is going to be a number field, primary key, set the unique or optional or a default value. All of that is with TypeScript. And then each table is just a model that you can import as a variable everywhere. In your seed file, you would ~like ~create the blog schema, then you would import a blog variable and use that to go query things.

Thanks. And that also gives you like a database object. You can write raw SQL strings if that's what you need to do. And it'll serialize it to make it safe. So you can go as like magic strings you want to, or as really dialed into types as you want to. And there's reasons you might want to go one way or the other.

But for an onboarding experience, it's really nice to just say db. select and then put in the big blog object. And then you get all of the types back out. For all the fields that are in a blog post.

Gotcha. Yeah. If you don't have a type safety, then [00:18:00] you don't exist

You don't exist.

So let's talk about the like database seeding, ~like ~how does that work? And like, how do you ensure that there's like fresh data every time the dev server started, or, ~I was like, ~I'm just curious how that all works out at a low level.

Yeah, and we've been playing with it based on feedback. So ~we had a pretty, ~we had a pretty different stance on seed data. Because whenever you create a new AstroDB project, you are just going to stand up a SQLite file locally. and it's meant to be just this throw away little database where you can throw random schema changes at it, you can throw new seed data at it and you're not gonna break production.

There's no API keys to get started in the dev server. Which is also really nice if you ever need to clone an example project or your friend sends you their general cadastral key. Astro website, you don't have to go set up a Vercel account in order to query the thing. Like you can just download it, create the SQLite file, and you can play with it.

And the way we did seeding is it will seed as soon as [00:19:00] you start up the dev server, or as soon as you visit a page that needs that data. So that means like it's literally part of the modules inside of your app. And every time you ~like ~edit the seed file, It will tell our bundler, hey, this seed file changed.

Rerun the seed file, and then reload just the parts that care about the seed data. So you'll see on your webpage a little live refresh, and it'll only hot module reload the parts that cared about the data. So it's really dialed in. It's smart enough to know seed data is kind of part of the build, and we can just re render to parts that changed.

So it's spun up on dev server start, It's meant to be throw away. So every time you start it up, it recreates the universe for you, and then you go, the parts that may change or like, should we let you persist a database? So if you restart the dev server, it doesn't recreate the universe.

There's some push and pull on how can the APIs be shaped and we're. really open to the feedback on that, since the whole tool is pre 1. [00:20:00] 0 at this moment. But I think for a default experience, just treating it as a throwaway SQLite file so you can experiment without breaking anything is just really freeing.

It's what people tend to do with Prisma DB push something dangerous. Like, why not just do SQLite file so it's always safe?

Yeah. I didn't realize the whole like HMR element to that. I think that's pretty insane to be honest, that you can just refresh specifically on the data you change. And I could definitely see the pushback on like persistent data, but I could also see the argument of if you actually need it, you can just seed it and then

Yeah,

from there.

Right. Um,

but yeah that's an interesting point. I'm interested where you all land with the community on persisting some changes potentially. ~Yeah, that's interesting. ~So let's talk about this, the Astro Studio platform. So what is it? And what is the, how does AstroDB play into it?

Astro Studio has always been a moving target of what does that word mean? At first, Astro Studio was going to be the name for the database, or the name for the place you look at it. [00:21:00] But, at this point we look at it more, As like the AWS console that you go to, to see all the services connected to your project.

So database, you can look at as just one of potentially many services that could be attached to an Astro project. So studios like the online viewer, where you go in there, you see your projects and you can also see like your databases, your usage metrics, where you have everything deployed. And also where you can Edit your data.

Studio is meant to be that hosted platform where if you want to go to production with Studio and you want to use a persistent database that outlives, like, all of your deploys, then you go over there in order to inspect and look at everything.

Gotcha. So as a user, I would use the studio platform to just manage deployments or make that like in a very easy UI to just manage ~all that stuff, ~all the infra stuff ~rather.~ Yeah. Okay.

Yeah, the infra stuff and also getting like an app token so I can go to my deployment host and say here's the token to [00:22:00] Talk to studio and then it will go query it. It'll make sure of everything and Set you up.

Gotcha. So it's ~like ~like the experience you would get ~like ~with other platforms, I feel like nowadays in terms of the DB SaaS stuff. 

Totally.

Awesome. So now that AstroDB has been out for a little bit, have you, or could you share like some specific use cases or examples where AstroDB has enabled developers to potentially unlock new features or improve their workflows?

Yeah, I feel like Authentication is weirdly a big one because we have people using starlight which is our documentation example And a common request is I have docs that are internal to my company or the tool we use. So we need an off gateway around this thing. And there's some related issues like how do you add middleware in front of a static site?

Because that's the use case people are doing. But now we do have the data primitive. Where you could use AstroDB to authenticate everyone and then you can go into your Astro site, [00:23:00] your Astro app, however you have it set up. So that's the one I'm really looking at because it just covers a wide array of things that you're trying to do.

But the example that we showed through the docs because it felt natural was like, A comment section or a like button, things that are additive to the websites people try to build with Astro, which is usually like marketing, blog, content, e commerce, maybe. So for those little cases where it's like, Ooh, I actually need to store the amount of likes on this post and respect the user session.

To figure out who's liking the post. That's a really simple use case to just say, Yeah, I'll go ahead and make a post likes table. I'll sort a number of likes, and I'll use Drizzle to make it a type safe query that I can go right. So like post to an endpoint, it writes to the database and I'm done. Same with comments.

Of course, with comments, you need to consider ~like ~spam, authentication, other pieces. So it's like a piece under the authentication and other services you might want. But it's another ~like ~additive option where you have this [00:24:00] static site already and now you want some dynamic pieces that rely on databases.

It just felt natural for that.

Yeah, that's pretty awesome. I didn't even think about having to auth docs because they are internal. ~It didn't even ~that didn't even occur to me in my head just now.

Yeah. It's like static site. Just put HTML somewhere. Anyone can look at

Yeah, everyone, it's public. It's fine. It's free. So one thing I'm curious about is the schema management in AstroDB. ~What is, ~what does that look like?

Yeah. So like actually changing a schema over time or that kind of

Exactly. Like migrations or what have you,

Yep. So we tried to go with. A more popular model now, I think it's just called schema migrations where you have your config and then you have a new version of that config. You made some changes, like you added a column instead of going to a migrations folder and writing the SQL to take it from old to new state.

We just do it based on diffing the old and the new schema. So you take the old one, you take the new one that has the new [00:25:00] column, and you figure out all the SQL queries that you need to get to that new state. And you can handle all of that running db push. So that will go look at the schema that's up on the production database.

It'll look at yours. It'll see what the difference is. And then it will figure out the queries that need to be pushed up. And we really cared about making it feel simple. So we have a GitHub CI action that comes with all the templates. And it's also something you can add. But every time you open a pull request, it'll actually verify.

That the schema changes you made are safe to make or if there are any that are pending So like you can make a pr to update the schema And then you get a little github bot that says schema change detected this column was updated when you merge into main This migration is going to be run So you get that nice visibility of this thing is about to happen.

And then when you merge into production, that will also trigger like the push in order to push up that migration. And [00:26:00] we're really strict about the things you can do in a migration. If you try to rename a column or there's potential data loss, we actually Prevent you from doing that, and suggest the expend and contract pattern it's called, where you like, do multi step, you add the column, you write to both columns, then you drop the old one, once you know no one's relying on that data anymore.

~We just thought, eh, ~Instead of trying to implement the perfect rename prompt, let's just lean on best practices because they're easier to do anyways. It's less complex, it will save you from any data loss problems, and we can just document that. That's the approach we went down. It will push everything based on diffs, it will tell you if anything's going to be unsafe, and then it walks you through the process of doing it safely.

is there an actual artifact that's outputted for migration? Or is it all just visual? Like on your studio or wherever you're seeing this.

Yeah, it's no artifact right now. We had a bunch of versions where we had one with the migrations folder, [00:27:00] but with a really big, do not touch, please don't modify these. ~It's ~if that's the case, if they are generated from diffs, why do we need to have that extra step? It is definitely just diffing schemas, and it'll show you results in the Studio Dashboard.

That's how we set it up.

Cool. I think I saw on the docs too. If you are performing something that's potentially harmful, as far as like data loss goes, I think there's like a force push essentially~ ~

~yeah, there's a force push if you're ~Because early in development, you don't have any users yet, and you just need to make the changes you need to make. Of course there should be a way to reset the universe if you have to.

Yeah. Or you just never have any users and you can just keep doing it forever.

You can just keep going, it's fine.

That's awesome.

relate.

Big flex. No, I'm just kidding. ~So I think, ~so the ability to develop locally with zero dependencies, I believe it was like a big benefit of AstroDB, especially like being able to use a database, but no internet connection. I think it's like a pretty big W, right? Can you explain how this feature works and how it streamlines the development process

yeah, [00:28:00] so it's pretty simple how it works. You're just creating a SQLite file based on your configuration and seeding it on dev server startup. If you have seed data. And that's kind of it. We do have a flag to change that. So if you just run dev, for example, that will stand up the SQLite file. But if you're saying, you know what, I'm online, I edited some stuff in studio and I want to connect to production and I want to look at it.

You can do dev dash remote, and that will look for a token and connect to studio. So that way you can actually see the live data and how that compares to what you're working on. And I feel like if you're doing more of a. CMS style thing like I have a website where I just dump all my YouTube videos It's nice to just say dev dash remote.

I see all the YouTube videos that I've been uploading and I can play with the dev server without worrying too much. Of course, you're playing with production. So don't write things, don't delete things, but if you're using it as like a read layer and you're just trying to read in everything that's [00:29:00] up there, it's a convenient little way to test stuff without having to do a production build.

So you have that on off switch for dev and also production builds. If you want to.

~going off? ~Going off the path a little bit, you mentioned you can connect a prod with a remote flag or whatever. Is it easy to just quickly dump prod data locally onto your

Ooh.

environment. Is that a thing yet or no?

it doesn't dump it. You can of course hit the export button and actually get the file and you could probably just put it where it's supposed to go and that would work. But yeah, it doesn't pull a local copy. It is going to query against production for that. It is a cool idea though.

If you just want to get Production data as your seed file and use it to generate a seed file. That could be a feature.

Yeah. I'm thinking of like the live debug stuff. Something happens in production, but my data is a match. Can I just quickly, depending on what data is in there, you might have to do like obfuscation or something, but could I just quickly swap and cause those bugs that only happen with prod data, those situations kind of things, that's ~what's ~what was going through my mind.

[00:30:00] I get what you mean. Cause similar feature to that as deploy previews where I need a copy of this, but I don't want to modify it. Because it's, SQLite, Torso Hosted Distribution, the door's definitely open to do it cheaply. We don't have to stand up a MySQL instance for every PR or every debug session.

So we could totally make it happen.

That's awesome. So lastly let's talk about how do you envision AstroDB evolving to meet the needs of all your developers in the future?

Yeah I feel like there's so much that I want it to do. Or I want the community to go try. And, it's early something that I'm working on right now actually is form actions, making it easier to write endpoints that query a database, because right now it's very primitive. You just, you write your JSON rest endpoint and you JSON stringify and you get the data back.

That is how the pioneers did it. And we've got the, we've got the request response patterns, but we need to make it more like [00:31:00] dialed in. So that you can make these live updating services and also build integrations that like stand up a database and endpoint to talk to it. And all of this other infrastructure stuff.

So it's just like you install these services and they handle the full connection from database to client code. So that's really where I want to see stuff go. But in the near future, I do want to see more people adding dynamic parts, like adding that contact form, that like button, those other features that you just thought that's too hard.

I'm not going to add that to my. Markdown file because the most I can do is just upload content like there should be more ways to build these like custom Experiences. I look at Kent C Dodds's blog or Josh Komu's blog where even though it's just a blog It has this full like experience where you can log in and say I'm a super fan and I can choose my avatar And I can upvote a certain post like it.

It does make stuff a lot more engaging when you open [00:32:00] those So that's what I want to see happen is just take your content and make it more dynamic

That's awesome. So pretty much an evolution of the sites being made with Astro effectively.

Yeah, don't want to sell it as now migrate your Facebook clone, migrate your Trello clone to Astro because we have a database. That's not gonna work. That's not meeting people where they are. I want people to do that. I'm trying to see how possible it is. But I don't know. It makes more sense to evolve into the stuff you want it to do anyways.

Awesome. I'm sure I'll talk to you again when AstroDB 2. 0 comes, so then we can address this question again and see What was right and what was wrong. But yeah, I think that pretty much wraps it up. And is there any do you want to plug anywhere where people can find you?

Yeah. I'm BeHolmesDev everywhere. Holmes as in Sherlock Holmes. I do Twitter videos, YouTube videos, trying to do more long form content like Talking about the Astro CloudFlare integration. It's been popping off lately. There's a lot of people that are using Astro as like edge [00:33:00] workers. So that's something I'm really excited about.

So tune into my YouTube. I'll be talking about that soon. And of course, join the Astro discord. Astrodot build slash chat, bunch of friendly people, support channels, docs, whatever you want to do.

Awesome, Ben. Always a pleasure to talk to you. Thank you for coming on.

Yeah. ~Yeah, ~this was awesome. Thanks.