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

31–40 of 310 posts

Re: Accidental database programming

#31

Post by carlsverre »

padjo wrote: post #29

Many times the thought “what if we just shipped the database to the client” has crossed my mind in large multi tenant apps where individual datasets were relatively small. I’ve never gone far with it as it seems sufficiently outside the norm to be a cursed architectural pattern. Would be nice to find out I was wrong.

I'm also interested to find out if it's cursed :) So far it's been a lot better than I expected. Apps like https://sqlsync-todo.pages.dev are trivialised with this pattern.

Tons of work to do in order to really prove it out though. But I'm pretty excited to keep pushing and see where this goes.

Re: Accidental database programming

#32

Post by culi »

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…

I like the implications of this to a "local first" architecture

Re: Accidental database programming

#33

Post by maclockard »

0xbadcafebee wrote: post #20

Anyone remember when "frontend applications" were actual applications and not web pages? I'm willing to bet we have reached that point where new devs literally do not remember that time. There comes a time [..] where we [..] need to cache data from an API. It might start off benign – storing a previous page of data for that instant back button experience, implementing a bit of undo logic, or merging some state from d…

> make the browser a full blown VM and just write normal programs that run in it

This is actually happening, albeit slowly, with recent efforts around WASM etc. If you want a fun hypothetical of where this all goes, check out the talk "The Birth & Death of JavaScript". Link here: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Accidental database programming

#34

Post by mhaberl »

0xbadcafebee wrote: post #20

Anyone remember when "frontend applications" were actual applications and not web pages? I'm willing to bet we have reached that point where new devs literally do not remember that time. There comes a time [..] where we [..] need to cache data from an API. It might start off benign – storing a previous page of data for that instant back button experience, implementing a bit of undo logic, or merging some state from d…

> Anyone remember when "frontend applications" were actual applications and not web pages?

I do. And also I remember building those apps. It was not as simple as building webapps today.

Yes, there are downsides to this model (a lot of them) BUT you can whip up a simple app with a beautiful UI in a couple of hours today. It was not like that 25 years ago.

Re: Accidental database programming

#35

Post by giancarlostoro »

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…

Genuinely curious why not just cache the relevant bits in LocalStorage / SessionStorage? I seem to remember Chrome trying to add a literal SQL database to the browser, but it never panned out, localStorage became king. I don't mean to downplay the usefulness, just I usually opt for what the browser gives me. I'm huge on WASM and what it will do for the browser as it matures more (or grows in features).

Re: Accidental database programming

#36

Post by maclockard »

neilk wrote: post #30
0xbadcafebee wrote: post #20

Anyone remember when "frontend applications" were actual applications and not web pages? I'm willing to bet we have reached that point where new devs literally do not remember that time. There comes a time [..] where we [..] need to cache data from an API. It might start off benign – storing a previous page of data for that instant back button experience, implementing a bit of undo logic, or merging some state from d…

You’re not wrong, but the web won because it had a superior delivery system: URLs. Everything weird about the web era of development has been about contorting everything to be URL-oriented. But consider how WASM is now turning the browser into an app delivery client. Not a “html and json bodged into an app”, but a real honest to god app. This project happens to be browser based because that’s convenient place to put…

Not just delivery, but also security. Browsers offer a level of isolation and safety that you generally don't get with native desktop apps. Things like iOS do bridge the gap a bit more though

Re: Accidental database programming

#37

Post by no_wizard »

giancarlostoro wrote: post #35
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…

Genuinely curious why not just cache the relevant bits in LocalStorage / SessionStorage? I seem to remember Chrome trying to add a literal SQL database to the browser, but it never panned out, localStorage became king. I don't mean to downplay the usefulness, just I usually opt for what the browser gives me. I'm huge on WASM and what it will do for the browser as it matures more (or grows in features).

IndexDB is even better, it supports a wider variety of data serialization, can be queried and versioned

Re: Accidental database programming

#38

Post by nikita »

My understanding is that we can sync any sqlite state to any other sqlite state using custom built replication.

Is this how it works and how does it update all the web components?

Would it work with all the frameworks or a custom framework is needed?

Re: Accidental database programming

#39

Post by rglover »

0xbadcafebee wrote: post #20

Anyone remember when "frontend applications" were actual applications and not web pages? I'm willing to bet we have reached that point where new devs literally do not remember that time. There comes a time [..] where we [..] need to cache data from an API. It might start off benign – storing a previous page of data for that instant back button experience, implementing a bit of undo logic, or merging some state from d…

> It's insane how much of the world's engineering effort and technology investment money has gone into putting lipstick on a pig.

I'm a JavaScript developer and yes, this is deeply disturbing. Even more so after I built a framework [1] that just copycats what PHP/Rails does (treat the server like a server, and the client/browser like a client—no SPA spaghetti). It works, it's fast, and makes development 100x easier.

I applied the same heuristic to deployments, eschewing all of the containers dogma and lo and behold, you can achieve great performance (and iterative speed) with old school, minimal tech (bare metal/VPS and just install deps and code directly on the machine).

[1] https://github.com/cheatcode/joystick

Re: Accidental database programming

#40

Post by no_wizard »

HatchedLake721 wrote: post #4

Unless I misunderstood, feels like I’ve been doing this with Ember Data since ~2013. https://guides.emberjs.com/release/models/ There’s also https://orbitjs.com/

Ember.js has had more innovations contributed to modern framework ideas than any other framework, really.

EmberData, Ember Routing, Ember Multi Applications (can't remember what its called, but its a precursor to microfrontends) all in one CLI tooling etc.

I could never understand what holds Ember back from being more used. I think it used to be performance but I think they addressed that with Glimmer many years ago.

Post reply on HN