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

151–160 of 310 posts

Re: Accidental database programming

#151

Post by pas »

_heimdall wrote: post #24
threatofrain wrote: post #17

Earlier quoted context omitted.

It's a very common trend for consumer-facing GUI's to have optimistic rendering, and if you're doing that then you're juggling client/server state. I still see spinning loaders here and then but they're generally for initial content load; e.g., does Gmail make you wait when you archive an email?

Not the GP, but I would include optimistic rendering on the list of common patterns that really are a bad idea. Optimistic rendering means your frontend and backend are tightly coupled, error recovery and synchronization is much more complex, and you are locked into (likely heavy) frontend rendering patterns that add even more complexity and coupling. We've spent well over a decade trying to avoid the fact that front…

the real UX goal is to minimize data loss (ie. provide the ability to resume whatever the user was doing, from a point that's as recent as possible), and for this it becomes necessary to provide "auto-save"

at that point there's already a diverging state problem, even if it's saved to localStorage (but obviously it's much better to save it on the server)

it's absolutely ridiculous that we spent the last 10+ years simply reinventing the same wheel (all low-level tools, Angular, React, Vue, rxjs, hooks, signals, whatever, etc), without providing the useful composable primitives for the hard problems.

and now there's yet one more thing on the frontend, SQLite. okay, there's a sync thing too. it's not like we didn't try it with that adorable DB (RethinkDB).

Re: Accidental database programming

#152

Post by carlsverre »

cheema33 wrote: post #135

I am getting the impression that this might work for small data sets. Does it work for large data sets? My webapp has to work with 100s of GBs of data in MS SQL Server. Admittedly, I haven't yet read the linked article. But, I plan to.

Currently, SQLSync copies the entire SQLite database to every client. So in order to support large datasets you would need to split up the data over many databases. Some applications can do this, some can't. It depends on the specific business and usage requirements.

Perhaps in the future, SQLSync will support partial replication which would enable this use case. As always there are trade-offs to consider with both approaches.

Re: Accidental database programming

#154

Post by cratermoon »

BackBlast wrote: post #139
neilk wrote: post #21

I’m familiar with this project - the creator is a friend. I’ll try to get him on here to answer questions. He’s a seasoned database architect. With SQLsync he’s made a way for frontend developers to query and update a remote database as if it was completely located right in the browser. Because it basically is. The power of WASM makes it possible to ship a whole SQLite database to the browser. The magic is in how it…

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.

Re: Accidental database programming

#155

Post by willsmith72 »

pas wrote: post #141
willsmith72 wrote: post #127

Earlier quoted context omitted.

i thought the whole premise of the article was that you don't want to do that, you want to cache some stuff, and instead of writing the cache stuff (a db) yourself, use a real db in your frontend. if you wanted to just fetch data from your server, it's not a problem anyway, right? a spa can also just fetch fresh data from a server. the whole point of the frontend cache was optimising ux/latency, e.g. for apps with gl…

I'm not a HTMX believer, so excuse my potential ignorance, but as far as I know the whole principle of HTMX is to keep things so simple that things cannot go out of sync. (Mostly because HTMX is basically a set of locally cute JS snippets helping with managing the very local interaction/state of a "user clicks button -> JS disables button, sends request to backend, waits for response, puts response somewhere in the D…

so for a typical spa, you can:

1. always refetch data. always in sync, but needs a server request, so it's slow.

2. cache some data on the client. faster, but you're "building your own database". can get out of sync (redux)

3. NEW: use SQLSync. fast, client & server stay in sync, don't have to "build your own database"

what you're describing just seems like number 1, right?

Re: Accidental database programming

#156

Post by 616c »

jchanimal wrote: post #64
commonenemy wrote: post #52

Earlier quoted context omitted.

That sounds awfully like Couchbase, which allows you to query/update databases that will sync to remote and the back to peers. And you can control the process (auth/business logic) with sever side JavaScript plugin with ease.

Creator of Couchbase Mobile here — I’m doing a new web-based thing[1] with a similar reactive API. I’m hoping that my encrypted block replication makes it more of a “data anywhere” solution than a “local first” database. But the paradigm of powerful databases in the browser is definitely one I’m glad to see becoming popular. [1] https://fireproof.storage/

Very exciting I shall as I was a fan of your prior project!

Re: Accidental database programming

#157

Post by carlsverre »

byteCoder wrote: post #153

"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton

I was so tempted to put this quote in the post! One of my faves. I'm also a fan of all the different variations: https://martinfowler.com/bliki/TwoHardThings.html

Re: Accidental database programming

#159

Post by hot_gril »

Coming from the backend world, I've only done small frontends that don't get this complicated. Assuming there are legit reasons for a FE to have complex state, a relational database is probably one of the first things you need. It's almost an automatic decision on a backend to have one, same should apply here. Using SQLite instead of Redux sounds reasonable.
Post reply on HN