HN user
Hacker
email me at mathews.kyle@gmail.com
Github is https://github.com/kyleamathews
my public key: https://keybase.io/kylemathews; my proof: https://keybase.io/kylemathews/sigs/vU0bed6I81ah3mr7DdfCiZxzAVSIeCuM8bELiMk8Aa0
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
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/
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 :-)
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.
From the twitter announcement: https://twitter.com/reactjs/status/913797447209517056
Also this is the source for the website: https://github.com/facebook/react/blob/master/www/package.js...
Part performance and part developer experience.
Gatsby generates HTML pages for each page so it loads as fast or faster than other static site generators but is way faster when clicking around the site as it prefetches pages and renders them in the client so the site feels like a local or native app.
It's also fully setup for building with leading modern web development tools like React, webpack, all CSS options including css-in-js, code splitting, PWA techniques, etc. so the development experience is excellent and you get production quality code without any setup.
Gatsby's ambitions are much higher than simply transforming markdown into HTML. See the writeup of the talk I gave recently describing Gatsby as a website compiler https://www.gatsbyjs.org/blog/2017-09-13-why-is-gatsby-so-fa...
It's by Facebook. They have 1.x billion users across their web and mobile products all of which run JavaScript. Tiny improvements in product performance equals big $$$. Easily justifies efforts like this. And the rest of us get to free-ride :-)
This is a very early release. I'm sure there'll be a "build for the web" mode soon enough.
I built a fairly large backend system using event sourcing ideas and am now using Redux for another backend tool I'm building. Redux and event sourcing are very similar. One big advantage of using Redux is there's tons of documentation and blog posts and plugins so you get a lot of power out of the box. E.g. it took me 5 minutes to add in support for the Redux devtools https://github.com/zalmoxisus/remote-redux-devtools.
Absolutely. Gatsby sites are built with React which means it's very easy to add interactive behavior in the client that communicate with a backend API.