bruchim

Is there an official production-ready solution for getting the 'Live Query' unofficial feature working? (I'm not talking about 'subscription')

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...

sure, I would be happy to hear more about it. Let me know how to contact you.

Thanks, super helpful. re Cloudflare, are you using them to reduce latency? what about a centralized database?

Expiration-based cache (e.g., 3 seconds) is not acceptable in this case, and more than that will reduce the load on the server + db dramatically.

Imaging subscribing to SQL query not just for a table; isn't it very complicated?

It's super simple for a simple demo app, not easy for a large scale.

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.

It looks very relevant to my problem! Have you used it? is it production-ready?

Agree.

Thanks! > It's fairly straightforward to write a websocket endpoint in whatever backend you have

It indeed solves half of the problem, but managing websockets for thousands of users is not that trivial IMO

Very interesting, thank you. I looks like a layer on top of your database, not a standalone baas, which is great. Have you used it in production?

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?

Specifically about performance, have you tried to solve it with any caching mechanism or any other out-of-the-box optimization?

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).