kylemathews

Very excited about Mastra! We have a number of Agent-ic things we'll be building at ElectricSQL and Mastra looks like a breath of fresh air.

Also the team is top-notch — Sam was my co-founder at Gatsby and I worked closely with Shane and Abhi and I have a ton of confidence in their product & engineering abilities.

We have a good solution in mind. Check back in a few months!

Check out our guide on writes — https://electric-sql.com/docs/guides/writes

There's a variety of valid patterns for writes & we don't want to be prescriptive about how you do them. We aim instead to help you easily use Electric with your preferred/required write pattern.

It's possible we'll write our own write library but it's equally likely we'll continue to find it better to partner with other projects building excellent libraries (like we are with https://livestore.dev/).

Another option too for scaling reads is just putting an nginx in your cluster.

Electric itself is quite scalable at reads too so for a SaaS use-case, you might not need any http proxy help.

Right exactly — a sync engine like Electric maintains replicas of data wherever you like. So natural places are web apps, mobile apps, backend services, etc. Here's an example showing how to sync a table from PG to Redis https://github.com/electric-sql/electric/blob/main/examples/...

It's dramatically faster to read from a local copy of data vs. sending the query to Postgres and can eliminate a lot of network and db load as well.

Posting the issue to GitHub would be great!

We have a job framework that can distribute image processing jobs on supported platforms* as well as automatically caching subsequent jobs. So it scales easily and as most builds don't have that many image changes (if any), the impact on warm builds is negligible.

* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/

yup, totally on us to prove the static model can scale!

We recently introduced build optimizations for incremental data changes for self-hosted environments: https://www.gatsbyjs.org/docs/page-build-optimizations-for-i... and are continuing to improve build speed across platforms.

To reliably provide near real-time deployments, we need tight integration with the CI/CD environment to optimize and parallelize the work; that's why you’ll see the fastest builds and deploys through Gatsby Cloud — the platform is purpose built for Gatsby!

Glad it's been a great experience!

Gatsby founder here.

Really appreciate the feedback and support for our launch today! The team worked super hard to get Incremental Builds live in public beta but are taking all the feedback (here and all over the web) as we go into full launch. Let us know what you think. Thanks!

Gatsby is widely used for documentation sites (check out sites on the showcase https://www.gatsbyjs.org/showcase/?filters%5B0%5D=Documentat...).

Typescript is rebuilding their docs on Gatsby right now and wrote up their reasoning behind the choice here: https://www.gatsbyjs.org/blog/2020-01-23-why-typescript-chos...

Gatsby's founder here:

If you can articulate what makes Gatsby seem odd to you — I'd love to hear it!

FWIW, lots of people do love Gatsby so perhaps there was a misfit with what you were looking for

https://twitter.com/i/moments/1194814354690125825

Yeah, it's built with Gatsby which has this sort of behavior baked in https://www.gatsbyjs.org/

Wow, you really hate Gatsby don't you?

Absolutely!

Gatsby tries to balance making your site work at some level offline w/ not precaching too much.

By default we cache the front page & then do "run-time" caching as the user visits different pages so ensuring they can at least return to the pages they've visited when offline.

We're building cloud products which complement the OSS product.

We launched our product, Gatsby Preview, into alpha in July https://www.gatsbyjs.org/blog/2018-07-17-announcing-gatsby-p...

A lot of people really love building sites with headless CMSs and Gatsby. Gatsby Preview gives content editors live preview of changes they're making in the CMS on a real version of the site.

We launched with support for Contentful and are adding support for other headless CMSs along with traditional CMSs running in headless mode like Drupal and WordPress.

Also check out our launch blog post https://www.gatsbyjs.org/blog/2018-05-24-launching-new-gatsb...

Same thing here :-(

Yeah exactly — it lets you grab content/data/images via the WordPress API.

Gatsby has a unique data system that let's you easily build static sites with WordPress/Drupal/other CMSes

* https://www.gatsbyjs.org/packages/gatsby-source-wordpress/

* https://using-wordpress.gatsbyjs.org/

If you want to see this in action in Gatsby, checkout https://using-gatsby-image.gatsbyjs.org/traced-svg/

It's super easy to integrate this into your site w/ our Image component & GraphQL fragment.

See the source code for the page: https://github.com/gatsbyjs/gatsby/blob/master/examples/usin...

And component documentation https://www.gatsbyjs.org/packages/gatsby-image/

Looks like Poe's law struck again :-)

https://en.wikipedia.org/wiki/Poe%27s_law

Awesome! Yeah, that was our main design focus. Make it feel like you're building a vanilla React web app but make it as speedy as the fastest websites.

Both. Checkout gatsbyjs.org, the tool the site was built with. But basically Gatsby renders each page to HTML and writes it out to disk similar to other static site generators. And then when the HTML loads, it pulls in JavaScript to make the site "live" so that from then on out it acts like a normal React web app.

Gatsby is an attempt to blend the best aspects of static site generators and web apps.