4 ms·

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 s

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.

j45 2y ago
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.
- ZitchDog 2y ago
  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.
  - j45 2y ago
    Have you tried Hasura by chance?
samwillis 2y ago
Solving this is high on my list with PGlite (https://github.com/electric-sql/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/ 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.
SparkyMcUnicorn 2y ago
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.
cpursley 2y ago
Check out WalEx for this, it doesn't suffer from the character limits of listen/notify: https://github.com/cpursley/walex https://github.com/cpursley/walex
jamwt 2y ago
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 https://convex.dev . Plug notice: this is my company.

j45 2y ago

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.

ZitchDog 2y ago
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.
- j45 2y ago
  Have you tried Hasura by chance?

samwillis 2y ago

Solving this is high on my list with PGlite (https://github.com/electric-sql/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/ 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.

SparkyMcUnicorn 2y ago

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.

cpursley 2y ago

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

jamwt 2y ago

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 https://convex.dev . Plug notice: this is my company.