Thanks!
Electric looks great! though I'm wondering how it works in scale.
I'm using Postgres and have some heavy queries, would be great to cache\materizlized the results instead of re-run them every time for every user, or for returning users without any change in the data.
Thank you for the detailed answer, you're awesome.
Electric-SQL, Convex, and Triplit are definitely relevant, and I'll dive deep into understanding their pros and cons.
In the meantime, I found another relevant one: https://squid.cloud/, which has a slightly different approach, more like full BAAS.
On one end, it can save me some time; on another, it's another stack my R&D needs to be familiar with.
just thinking about implementing incremental materialized views and maintaining web sockets with clients makes me nervous, but maybe I'm the only one.
Have you implemented such a solution e2e? from db to frontend?
We are using Apollo on top of our Postgres db, which is also used for other CRUD REST APIs.
I'm basically looking for more perspective of other teams, if they are feeling the same after migrating to graphQL (the same query in simple node + SQL ORM took half of the time), and if there is something that helped them solve these problems.
e.g. caching graphql is not as easy as caching GET API, something that I didn't know before.
TBH, I summarized here almost a year of a process into a single paragraph, maybe it's my bad.
A few engineers with good performance minds have already benchmarked and improved some of the queries, and we learned a lot from the process.
My general feeling is that for the average developer, graphql can lead to some serious performance issues, and I wonder if it's just my experience or we are doing something wrong.
D1 is currently limited to 100 MB, and I'm doubtful it's meant to be a complete database. As I understand it, it's more for "manual cache" purposes and not for hosting everything there (think about 100 TB of data).
Regarding your second comment, while it's true that all the solutions you mentioned allow you to deploy a DB, they are offering between 5-10 locations around the world, compared to 100+ locations of Edge solutions.
Anyway, that's not the main point. I still don't think it's the right way to create read replicas for all your data in all locations. There should be a better way to copy only the relevant data (the data you want to fetch with low latency).
I've found some [1] [2] [3], but they're either archived or not ready for production.
I want to register from my clients (frontend app) for specific (can be complex) queries and get updates on changes.
[1] https://github.com/n1ru4l/graphql-live-query [2] https://www.graphile.org/postgraphile/live-queries/ [3]https://grafbase.com/blog/simplify-building-realtime-applica...