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

201–210 of 310 posts

Re: Accidental database programming

#201

Post by jchw »

cratermoon wrote: post #198
sp332 wrote: post #194

Earlier quoted context omitted.

Yes but targeting WASM and SQLite minimizes that pain quite a bit.

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

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

This sounds like the set up for a "No? Me neither." punchline. Certainly one of the features of Flash is that it gave you fairly good consistency across computers, but honestly my perception of Flash wasn't that it was going to solve some grand web problem, but more "oooh look, shiny rollover buttons!" and "ooh look, super obnoxious advertisement that forces people to pay attention to it!"

Re: Accidental database programming

#202

Post by recursivedoubts »

emmanueloga_ wrote: post #182
recursivedoubts wrote: post #174

Earlier quoted context omitted.

i don't think htmx is very opinionated: it generalizes hypermedia controls in HTML and that's about it. No strong opinions on how you use it beyond that, can work reasonably well w/ any back-end that produces HTML. The goal is to expand the set of UI use cases that can be cleanly expressed in HTML w/o resorting to (user) scripting. Yeah, htmx is 3800 LoC, and you could do an 80/20 version of it for a lot less, but th…

My tone was a bit strong—my bad! I appreciate your thoughtful response. I must add I realize running an OSS project and writing a book is a massive effort. Big respect for not just sharing ideas but actually implementing them.

no problem at all, i get that htmx isn't for everyone and certainly that the shitposting can be a bit much at times. i appreciate your comment!

Re: Accidental database programming

#203

Post by pxmpxm »

BackBlast wrote: post #164
cratermoon wrote: post #154

Earlier quoted context omitted.

Yay, we're moving back to fat clients! What has been is what will be, and what was done is what will be done, there is nothing new under the sun.

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.

Re: Accidental database programming

#204

Post by barumrho »

vemv wrote: post #62

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

Only for some class of websites with limited interactivity.

On iOS/Android, before all the WebKit apps took over, many apps would use a local SQLite database to support offline edits and implement a syncing protocol to the server. It's a lot of work, but the end product can be quite handy. (This is how you'd expect your email client to work, for example.)

Re: Accidental database programming

#205

Post by BackBlast »

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.

I work with lean, business speculative software mostly. Which means not cross-platform native development is simply not economical to do. I generally need to be able to hit Windows, iOS, Android, and MacOS square on with one code base.

A "native" electron or capacitor distribution system is a fine extension of a local-first web client. And an advantage of building fat clients generally is they lend themselves to such distribution models much easier than say, htmx or hotwire.

Native fat client have had their benefits and lots of people still prefer them, but always had the drawback of manual data management and installs. Being able to leverage any device you own with a cloud synced local-first client really gives you the best of both worlds.

But not all software fits readily within this model.

Re: Accidental database programming

#206

Post by chrisjc »

Sorry for perhaps reducing what SQLSync does to any over simplistic description, but is it effectively applying the CRDT pattern on top of the client (SQLSync/sqlite) and servers (Some OLTP) individual operation logs?

edit: I mean rebase, not CRDT

Re: Accidental database programming

#207

Post by BackBlast »

cratermoon wrote: post #188
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.

Great until you have to support n versions on m platforms and half your customers are enterprisey and stay on a 6-year-old version from before your last LTS version on a now-unsupported platform because they built a core part of their business processes on a a misfeature.

I've worked on various forms of "legacy code" for most of my career. As long as the economics line up and the customer is willing to pay for the required support, then it's a fine business avenue.

If economics don't line up then you have to pull the plug and set them adrift, which is much easier and more secure with a fat client that runs without a server than say, a complex cloud system.

Re: Accidental database programming

#208

Post by vemv »

barumrho wrote: post #204
vemv wrote: post #62

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

Only for some class of websites with limited interactivity. On iOS/Android, before all the WebKit apps took over, many apps would use a local SQLite database to support offline edits and implement a syncing protocol to the server. It's a lot of work, but the end product can be quite handy. (This is how you'd expect your email client to work, for example.)

One could also argue, this class of websites is what the majority of the website/webapp landscape should be.

An average SPA is, in the end, a website for most users. Take a payment form for instance - we had those 10, 20, 30 years ago, with 0.1x the effort.

Of course there's place for fat client tech, but there are 1000 websites for each 'email client' - exceptional cases often dominate the discussion.

Re: Accidental database programming

#209

Post by BackBlast »

tdeck wrote: post #193
BackBlast wrote: post #139

Earlier quoted context omitted.

I find that moving the full query system into the front end is where most front end devs really want to be. They want a full power query system for the data instead of continuous rounds of re-inventing the transport layer, REST, GraphQL, *RPC, etc. It's hard to adopt such a system in most traditional web shops with their specialized backend and frontend teams. You're pulling out the database, backend, transport, and…

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 "authority" which trumps the others. The server is simply a central hub that requires the right authentication to allow the sync process to happen.

When you want to create a set of data that crosses user boundaries, it gets complicated. It's possible to do, but you're not on the easy train anymore.

Creating a system that's both easy to use, and scopes the right data view out of the system wide tables and rows we usually think of databases, is not the CouchDB nor SQLSync model.

Re: Accidental database programming

#210

Post by whoisthemachine »

cratermoon wrote: post #154
BackBlast wrote: post #139

Earlier quoted context omitted.

I find that moving the full query system into the front end is where most front end devs really want to be. They want a full power query system for the data instead of continuous rounds of re-inventing the transport layer, REST, GraphQL, *RPC, etc. It's hard to adopt such a system in most traditional web shops with their specialized backend and frontend teams. You're pulling out the database, backend, transport, and…

Yay, we're moving back to fat clients! What has been is what will be, and what was done is what will be done, there is nothing new under the sun.

Those pesky backends are so annoying, so why don't we just put a backend on every client?
Post reply on HN