Live data from Hacker News

Accidental database programming

sqlsync.dev

191–200 of 310 posts

Re: Accidental database programming

#191
post #158

as a frontend dev that went fullstack, i had a similar path too: https://dx.tips/oops-database

swyx! I can't believe I missed this post. This is gold. Thanks for sharing!

haha yours is better. nice work and keep up the good fight. am in sf if you ever want to get coffee

Re: Accidental database programming

#192
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.

The correct answer is to move the UI back to the server, where the database already is, and just send html to the client side html renderer (or "web browser"). This whole post is just "front end and gone off the rails, over the cliff, and into the ocean."

Re: Accidental database programming

#193
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…

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.

Re: Accidental database programming

#194

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.

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

Re: Accidental database programming

#195

Earlier quoted context omitted.

Firefox fought against WebSQL. Firefox then re-implemented indexedDB with SQLite on their own browser. Firefox has now largely faded into obscurity.

The issue was that a specific library would be pinned at a specific version for the rest of the history of the web. As good as SQLite is, I hope to hell we're not still stuck using it to handle mining operations in the oort cloud in 200 years.

This is why wasm is great. Webpages can just ship whatever version of SQLite they want. And/or eventually migrate to something better.

Re: Accidental database programming

#196
post #69

Earlier quoted context omitted.

But , if I can be honest, solutions such as Hotwire or Livewire are not as snappy as a SPA. I personally prefer InertiaJs [1], which is some kind of front-end router system with its state synced with the server in an "old style" fashion. [1] https://inertiajs.com

I don’t know what SPA’s you have the pleasure of using, but most SPA’s I’m subjected to are an exercise in molasses like interactions and loading spinners.

Yeah, they are building SPAs incorrectly by relying on something like `react-query` which is waterfall rendering land. People don't truly understand the sacrifice they are making by using `react-query`. It isn't designed for large scale SPAs, it's designed for small sites that just need to fetch a little data.

Re: Accidental database programming

#197
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…

> It doesn't easily map to the data-structures you want in your client code

I disagree. Normalizing data is critical for FE reactive applications, keeping data up-to-date basically requires it; all CRUD operations are much easier to handle.

Re: Accidental database programming

#198
post #194

Earlier quoted context omitted.

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.

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?

Re: Accidental database programming

#199
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?

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

Re: Accidental database programming

#200
post #130

Earlier quoted context omitted.

you can only have one person work on the code at a time? that seems, very very obviously dumb

I can change A to B on my own, you can change A to C on your own. At some point we have to communicate which change is correct. It does not have to be synchronous and it might be via commit message - but still change alone is not enough for conflict resolution. If you edit word document and someone then changes something there is no commit message but might be comment on document, email or im.

Unison has a neat approach to this problem: References are hashes of the abstract syntax tree, the only way to write a "collision" is to write an identical function--which isn't actually a collision at all.
Post reply on HN