Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accidental database programming

sqlsync.dev

Post reply on HN
Print view View original

231–240 of 310 posts

Re: Accidental database programming

#231

Post by holoduke »

roenxi wrote: post #102

There is an interaction here between the "what gets measured gets managed" principle and the sunk cost fallacy. The problem with databases is actually complexity. Any individual feature is more or less safe, but around the time reliability, caching and indexes get matched together there is a complexity explosion and it doesn't (normally, anyhow) make sense to implement a domain-specific DB (call is a DSD?). But, arou…

What is exactly hard about sql? Every dev imho should know it. And sql syntax is good and proven too be long lasting. Maybe investing some time in actually learning it instead of bashing it will help you further.

Re: Accidental database programming

#232

Post by ako »

BackBlast wrote: post #209
tdeck wrote: post #193

Earlier quoted context omitted.

How is this approach meant to handle data visibility and access control? Often a large part of a backend is materializing raw data into a form that the active user is allowed to view.

So if the user owns all their own data, their "data view" is their data set. A To-Do system, a personal finance app, any kind of note-taking or personal record keeping fits this model. You create a database per user and the auth and sync are all self contained within that database. This system is multi-master, which means that any change on a client or on the server will be replicated to every other. There is no "aut…

> When you want to create a set of data that crosses user boundaries, it gets complicated.

So it sounds like this excludes most enterprise use cases?

Re: Accidental database programming

#233

Post by cpursley »

matlin wrote: post #7

I'm currently writing a very similar article about "full-stack databases" which highlights the same pattern where many apps end recreating the logic of our backend and database in the frontend client code. The solution we're promoting is to choose a database that can run on both the server and in the client and then sync between them. The reason we aren't using Sqlite for our product is because Sql is frankly not the…

Actually, Postgres provides a great way to subscribe to real time changes via the WAL. I even maintain an open source library for this:

https://github.com/cpursley/walex

Re: Accidental database programming

#234

Post by cpursley »

matlin wrote: post #10
johnny22 wrote: post #8

Earlier quoted context omitted.

postgres has some capability to do that, but does need a server.

Yeah you can subscribe to overall changes to the data on a row by row basis but can't subscribe to an actual query. Many apps and libraries imitate reactive queries by just refetching all queries from Postgres when any data changes or just repeatedly polling the query every 10 seconds or so but this puts a lot of strain on the database. You can just subscribe to the replication stream but then you're left trying to r…

Could you explain in more detail the use case for subscribing to the actual queries (instead of the change events)?

Re: Accidental database programming

#235

Post by password4321 »

pxmpxm wrote: post #203
BackBlast wrote: post #164

Earlier quoted context omitted.

I'm on the fat client train with my company and I nudge my clients that way if they're open. It's just a great way to build a system.

Ohh can't wait for the inevitable next step of dropping the "web" part of web assembly and doing, ya know, native fat clients again.

Excel is a great fat client. Writing a sync in VBA is not, but some of the pieces are already there.

Re: Accidental database programming

#236

Post by password4321 »

sp332 wrote: post #199
cratermoon wrote: post #198

Earlier quoted context omitted.

Remember when targeting Macromedia Flash was going to solve the web compatibility and interactivity conundrum?

Yeah? It was targeted for destruction by Apple because it was buggy and insecure, not because it wasn't delivering.

Don't forget horrendous mobile performance (battery drain)!

Re: Accidental database programming

#237

Post by lmm »

pdonis wrote: post #144
nusmella wrote: post #65

An old company I worked for used project management software with a check-in/out mechanism for making changes. When you "check out" a project it downloads a copy that you change locally, then "check in" uploads it back to the server. A project is "locked" while in the "checked out" state. We all felt it was an archaic mechanism in a word of live updating apps. After 10 years of building SPA "web apps", that data sync…

What many people either can't or don't want to acknowledge is that ultimately whether or not you support live updates in parallel by multiple users, instead of locking so only one update can proceed at a time, is not a technical decision, it's a business decision: do the business rules that are appropriate for your application enable you to deal with concurrent live updates or not? Ultimately that comes down to wheth…

Nah. I've seen plenty of systems where the business rules would handle concurrent updates fine, but since they're using a traditional Web/ORM/RDBMS setup they build a last-write-wins system without thinking about it. It's one of those rare problems where the technical part is actually harder than the business part.

Re: Accidental database programming

#238

Post by fho »

Terr_ wrote: post #172
pdonis wrote: post #144

Earlier quoted context omitted.

What many people either can't or don't want to acknowledge is that ultimately whether or not you support live updates in parallel by multiple users, instead of locking so only one update can proceed at a time, is not a technical decision, it's a business decision: do the business rules that are appropriate for your application enable you to deal with concurrent live updates or not? Ultimately that comes down to wheth…

Indeed, many of the most painful technical problems are actually three business problems in a trenchcoat.

So true ... and often those business decision are not yours to make.

Re: Accidental database programming

#239

Post by hax0ron3 »

Relational databases are mathematically elegant and useful in certain ways for arbitrary data retrieval and manipulation, but I don't see why they would be the best fit browser-side for any but the absolute largest and most complicated front-end systems.

Is the typical in-browser code really complex enough that one would want to introduce the object-relational mismatch and all of its associated issues?

Most in-browser code wants to operate on a limited set of very well-defined tree data structures, which is a bad fit for relational databases because relational databases are designed to represent a generic graph that can be virtualized into a tree arbitrarily and as necessary.

Re: Accidental database programming

#240

Post by crubier »

remram wrote: post #171
crubier wrote: post #98

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

> LoFi (Local first) Are we set on this abbreviation? Cause it's super confusing.

I agree it's super confusing actually, lol. I've seen people using it and it's cool, but a non-overloaded one would be better!
Post reply on HN