[HN Gopher] Astro DB
___________________________________________________________________
Astro DB
Author : MatthewPhillips
Score : 144 points
Date : 2024-03-12 17:34 UTC (5 hours ago)
(HTM) web link (astro.build)
(TXT) w3m dump (astro.build)
| dfreire wrote:
| So what's the added value over Turso + Drizzle?
| explodingcamera wrote:
| It seems to be wrapping drizzle, with astrodb just being a way
| to deeper integrate it into the framework and adding some ease
| of use features. Also seems like a nice way to support the
| development of astro by using their hosting service.
| mati365 wrote:
| So it is the wrapper for wrapper (Drizzle) for Kysely?
| explodingcamera wrote:
| As far as I can see from looking at their repo, Drizzle
| isn't a wrapper for Kysely though? You can use Kysely or
| other query builders with drizzle, but it has its own query
| builder too.
| ssernikk wrote:
| A lot of Astro news for the last 2 days:
|
| - 4.5 release
|
| - Volar $10,000 grant
|
| - Astro Studio/DB
| thejazzman wrote:
| They call these "launch weeks"
| snide wrote:
| Comments coming from a years-long Astro user that loves it. I use
| it to power my own website. I'm familiar with this space because
| I also work at Xata (take that as a disclosure).
|
| This looks like a pretty simple data solution that might work for
| Astro's audience (content sites and hobbyists). They've split the
| hosting into their studio product to provide a way to earn
| revenue. Essentially you host the DB with them and can access it
| remotely, but could also host it however you want, you'd just
| lose the Studio editor.
|
| The Studio editor itself is pretty basic at the moment with a
| table view and a way to check SQL calls. You can't build schemas
| in the UI yet and what you get is mostly a dev wrap of existing
| tools (like Drizzle) that let you interact with your DB. Their
| demo shows the limitations here, with things like "email" not
| being able to validate in the studio editor. My guess is that's
| coming later, but I might have missed it in the docs. Either way,
| it's nice that your config is stored at the code layer.
|
| Most of these small websites that Astro is great fit need small
| CMS systems, and studio doesn't look to provide any way to deal
| with images (at least on first check) so that's sort of a bummer.
| You'd need to wire up some references with Cloudflare I guess.
| Still reading here, but it'd be cool if that came natively.
| Storing, retrieving and resizing images is a pain. The column
| types allowed are pretty small (text, number, bool, date, json).
|
| While simple. It looks like it'll be relatively speedy with
| retrieval because of it.
|
| Right now though, as an actual CMS editor (which my guess is what
| most Astro folks really want) Studio feels way to simple to tell
| a client to use. I'm interested to see whether they go more in
| the direction of a generic database store (implied from the name)
| or more of a CMS to compete with the natural pairings of
| Contentful, Statamic and others. Webhooks as a launch feature is
| great! That'll help folks out.
|
| Either way. I love this team and their perspective. They build
| cool stuff, open source a lot of it (check out Starlight for
| docs), and I'm excited to see where this one goes over time.
| Congrats on the launch.
|
| Now I need to update my Astro site to 4.5 :)
| azangru wrote:
| > a years-long Astro user that loves it
|
| Have you tried Eleventy? If you have, how, in your opinion,
| does Astro compare?
| snide wrote:
| Been awhile with eleventy, but I really like the "islands"
| concept from Astro. It lets me break out into Svelte when I
| need for server stuff. Astro is also excellent at building
| shiki, TS and content generation together natively.
|
| Overall it feels a little less bare bones, while still being
| flexible.
| amadeuspagel wrote:
| Love that they use comments as an example. I miss this with many
| static blogs. HN comments are great, but I sometimes want to read
| a discussion between people who've actually read the article.
| dosplatos wrote:
| Personally, I love Astro and use it personally (and at work). I
| hope this turns out as a great start to generating revenue.
| gigatexal wrote:
| Interesting and even more compelling pricing, indeed a very
| generous free tier.
|
| I only wish this wasn't a javascript heavy thing and that I could
| interface with it in my language of choice. But as it says on the
| tin this is integrated well for the greater Astro ecosystem.
| drewda wrote:
| I get that all of the current generation of front-end/back-end
| frameworks promised their investors that they'd figure out how to
| sell developer services, rather than just offer open-source
| components with some extra commercial support options...
|
| But I do wonder how this type of thing will actually compete
| against a billion headless CMSes and a million PaaSes already on
| the market...
| shafyy wrote:
| > _But I do wonder how this type of thing will actually compete
| against a billion headless CMSes and a million PaaSes already
| on the market..._
|
| They won't. I, for one, hate that runtimes like Deno and
| frameworks like Astro start offering paid infrastructure. This
| smells like lock-in from a million years away.
| brianzelip wrote:
| > smells like lock-in from a million years away.
|
| I worry too, but here you can export as sql and csv.
| tutfbhuf wrote:
| I'm currently thinking about using either Astro or SvelteKit for
| my next project. Astro DB suggests that Astro aims to be more
| than just a static site builder. However, all over the internet,
| I read that Astro is primarily a static site builder, and if I
| want to build a fully-featured web application, I should use
| something like Next.js or SvelteKit. Now, I'm a little bit
| confused where Astro DB fits into this picture.
| ricardobeat wrote:
| It used to be a nice site builder, for static sites and apps,
| but has grown into another full-featured framework of sorts.
| And is now sliding into SaaS.
| davepeck wrote:
| I dig Astro and use it to build my blog and several other tiny
| mostly-static sites. I'm not sure that the hosted database
| service fills a need I have but, in general, supported SQL
| integration seems like a useful addition.
|
| As an aside: there are days when I wish I could avoid using the
| Astro component model entirely, do everything in Preact (or
| whatever), and still use the `client:*` directives when
| appropriate. I realize this is easier said than done and also
| probably not a reasonable thing for Astro itself to try and
| target -- but moving between Astro components and framework
| components always has just enough friction that it's something I
| think I'd enjoy using.
| eyelidlessness wrote:
| This is probably the main reason I wouldn't choose Astro for
| personal projects where it's otherwise a great fit. I think it
| would have been a more reasonable thing earlier on in product
| conception, but quite a lot of assumptions are now baked into
| their own custom template language. Which I'm sure is quite a
| nice template language, but it's already hard enough to get all
| the tools to work nicely together without adding another one.
| davepeck wrote:
| Yeah, I started poking at Vite to see how much work it would
| take to build an island-architecture-for-preact tool on top
| of it. It looks doable.
|
| Out of curiosity, when you're building a mostly static site
| that might want occasional islands of interactivity, what do
| you reach for instead?
| bensmithett wrote:
| > mostly static site that might want occasional islands of
| interactivity
|
| is exactly what I made this for
| https://github.com/bensmithett/tropical-
| utils/tree/main/pack...
|
| It's a little more verbose and doesn't quite have the
| ergonomics of Astro client:* directives, but it does the
| trick for me.
| biggestlou wrote:
| https://github.com/ElMassimo/iles
| byt3h3ad wrote:
| Astro on a roll lately! Excited for the rest of Launch Week
|
| https://x.com/astrodotbuild/status/1767294849848582202
| oDot wrote:
| Slightly tangential -- anyone knows how does libSQL compare to
| upstream SQLite for shipping with a desktop app or in the browser
| via wasm?
|
| Edit: I've read the readme, hoping for a take from anyone who
| gave it a try
| seabass wrote:
| The ORM API is very reminiscent of Drizzle, which I think was a
| great call on Astro's side. I have so far only used Astro for
| SSG, but seeing code like this [1] has me interested to see how
| far it can go for SSR tasks that you might currently use
| metaframeworks such as Next/Nuxt/SolidStart/SvelteKit for.
|
| [1] https://docs.astro.build/en/guides/astro-db/#insert
| jer0me wrote:
| It actually is Drizzle
| MatthewPhillips wrote:
| Hey, I'm one of Astro's co-creators, happy to take any questions
| on Astro DB you may have!
| internetter wrote:
| Hi Matthew. Both Cloudflare[1] and Turso[2] have apparently
| very similar offerings at what appears to be better pricing.
| What does AstroDB provide to warrant the additional cost?
| +----------+------------------------+----------------+---------
| ------+ | | Base Storage + Cost/GB | Reads
| | Writes | +----------+------------------------+--
| --------------+---------------+ | Astro DB | 1GB + $1.00
| | 1b + $0.001/m | 1m + $1.00/m | | D1 Free | 5GB
| | 150m | 3m | | D1 Paid | 5GB +
| $0.75 | 25b + $0.001/m | 50m + $1.00/m | |
| Turso | 9GB + $0.75 | 1b + $0.001/m | 25m +
| $1.00/m | +----------+------------------------+----------
| ------+---------------+
|
| [1]: https://developers.cloudflare.com/d1/platform/pricing/
|
| [2]: https://turso.tech/pricing
| MatthewPhillips wrote:
| First, we have just launched and are still figuring out
| pricing, this is a great point of feedback that we'll
| consider, thank you.
|
| What differentiates Astro DB is the deep integration with the
| Astro framework and providing an easy path for common
| scenarios. Astro DB is a higher-level product than using a
| database service directly. For example, Astro DB handles
| migrations transparently for you and guides you when manual
| intervention is needed, just from running `astro db push`.
|
| Astro DB also includes a local story, by default you use a
| local SQLite database that you can seed (using db/seed.ts)
| for local development. You can even use it for a purely
| static site, although we're still working on making SSG use-
| cases more seamless. For now though, this gives you a great
| local workflow for development that you can think easily
| connect to production with `astro build --remote`.
| LostLocalMan wrote:
| What do they do to mitigate the roundtrip latency introduced by
| using a hosted database on a separate network? Is the idea that
| you wouldn't use this if you have pages that do many queries to
| render?
| MatthewPhillips wrote:
| This is a very good question! One of the big reasons we
| partnered with Turso was for their edge network, so replicas
| are available close to your origin server. Being able to host
| anywhere is something that's important to Astro, so this felt
| like the right balance. Turso is known for its speed and one of
| the main thing that attracts people to use it.
| LostLocalMan wrote:
| Gotcha, so you guys use readonly edge servers and just eat
| the latency on writes
| factormeta wrote:
| so it is basically using libSQL instead of SQLlite?
| MatthewPhillips wrote:
| It does use libSQL, yes!
| remram wrote:
| Had to look this one up, "libSQL" is the name of Turso's own
| one-way-compatible fork of SQLite.
| DrDroop wrote:
| How is something like this or other services like cloudflare's D1
| an actual scalable solution for any serious app? Is it the
| pattern where you give every customer, team or "workspace" it's
| own database and manage this through some distributed kv store? I
| am just trying to understand how this is a relevant solution and
| not some weird SQLlite fetishism you see going around.
| pmcf wrote:
| Not to be confused with Astra DB, Cassandra as a Service..
| http://astra.datastax.com
___________________________________________________________________
(page generated 2024-03-12 23:02 UTC)