Hacker News Reader

Comment by ZitchDog | Hacker News Reader

One thing that postgres does not solve very well is reactive UIs. Postgres does have listen/notify but it requires much more boilerplate and infrastructure to set up than Firebase/Firestore. For example I'd like to be able to run a query and get notified that the results have updated when any of the affected rows change.

View on HN

Solving this is high on my list with PGlite (https://github.com/electric-sql/pglite). I have a bunch of iteas/thoughts that I hope to get to at some point (IVM, streaming queries, result diffs).

When PGlite (or SQLite) is used with Electric (https://electric-sql.com/), we already provide good reactive primitives. But we hope to improve this so that where possible the full queries don't have to be re-run.

I've been very happy using Hasura on top of pg.

There are several fantastic options that remove the need to manually write resolvers, set up subscriptions, solve N+1, reinvent the wheel, etc.

Agree. If you want a fully reactive database (and not just hierarchy-based reactivity like Firebase) but want to keep your ACID + relational data modeling, check out https://convex.dev .

Plug notice: this is my company.

Check out WalEx for this, it doesn't suffer from the character limits of listen/notify: https://github.com/cpursley/walex

Could a simplification of reactive UIs be a possible angle?

Part of me is thinking about htmx or something from alpine and wondering if it’s enough. Shoutout to livewire too.

Htmx doesn't help with this problem (knowing whether the underlying data has changed in order to update the UI). It's a common problem in any kind of collaborative app.

Have you tried Hasura by chance?

Reply on news.ycombinator.com