In other words, "let me show you how to turn your super cool project into a CRUD app".
Accidental database programming
91–100 of 310 posts
Re: Accidental database programming
#92Offline/local-first based on SQLite seems hot right now. Third one I’m reading about this week. And it sounds good to me! But how does it compare to ElectricSQL[1] and PowerSync[2]? [1] https://electric-sql.com/ [2] https://powersync.com/
Indeed it's a very hot space! So exciting to see all the different approaches. ElectricSQL and PowerSync are both tackling the very hard problem of partial replication. The idea is to build a general solution which allows a traditional centralized db to bidirectionally sync only what's needed on the client side - while still supporting optimistic mutations (and all the consistency/conflict stuff that goes along with…
>But consider a personal finance app. The main goal is cross device sync, cloud backup, offline capable, etc. In this case having the entire db stored on every device is probably what you want.
A bit confused by this. If I'm a developer of a PFM, I don't want anything but a single user's financial data synced to their device. This sounds like partial replication to me.
Re: Accidental database programming
#93Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discussions?).
I'm very happy to see the discussion thus far. This first post focused on the parts of frontend engineering that motivated me to create SQLSync rather than specifically how SQLSync works. I'll be addressing that in my next post. Thanks for all the great questions! Keep them coming :)
Re: Accidental database programming
#94Interesting. How does server side validation and access control work with this?
Good questions! Validation can be handled in the reducer layer. Since the reducer logic re-runs on the server, it can do anything including reaching out to server-side resources like authorization or other dbs to ensure the client isn't doing anything fishy. It's also possible to use the full capabilities of SQLite to execute automatic in-db validation via triggers, constraints, checks, etc. Access control is more di…
Please, please don't store any passwords, health, or financial information in your stack unless you solve this!!!!
Re: Accidental database programming
#95This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
i don't get it, how does that solve the same problem for an interactive website?
Re: Accidental database programming
#96Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discussions?). I'm very happy to see the discussion thus far. This first post focused on the parts of frontend engineering that motivated me to create SQLSync rather than specifically how SQLSync works. I'll be addressing that in my next post. Thanks for all the grea…
Thankyou for the very informative article, I appreciate the irony using a post titled "Stop building databases" to announce a new database :-)
Re: Accidental database programming
#97This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
It disappears if your customers have reliable networks, and they are either close enough to the datacenter that the database is in, or you have sufficiently smart database replication. So, often, the problem comes back, but you're synchronizing between datacenters. Running server-side does seem to be one of the problems SQLSync wants to handle? I wonder how well it does at that compared to other ways of doing it?
Precisely an implied part of my point was, server-side caching, DB replication, CAP, etc are all relatively well-understood problems.
One can solve those without reinventing the database, as the article denounces.
Re: Accidental database programming
#98This is very exciting, I really love the LoFi (Local first) wave.
The need to write the reducer in Rust for now is a big bummer. Rust is cool, but JS is easier to get started quick.
ElectricSQL is an alternative which is cool too.
Re: Accidental database programming
#99This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
i don't get it, how does that solve the same problem for an interactive website?
If you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)
Re: Accidental database programming
#100This is very exciting, I really love the LoFi (Local first) wave. The need to write the reducer in Rust for now is a big bummer. Rust is cool, but JS is easier to get started quick. ElectricSQL is an alternative which is cool too.
Yea, 100% agree. I'm starting to figure out what that looks like in this issue: https://github.com/orbitinghail/sqlsync/issues/19