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

A future for SQL on the web

jlongster.com

Post reply on HN
Print view View original

141–150 of 227 posts

Re: A future for SQL on the web

#141

Post by gunapologist99 »

EvanAnderson wrote: post #4

This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…

Another, probably not insurmountable, issue with SQLite in the browser (without having a formal specification that could produce cross-language alternatives):

Using SQLite results in a new, built-in reliance on a C library. Even though most languages can use C library bindings, it does present some issues in some build scenarios, such as static builds, and, given the enormous scope of SQLite, would prevent anyone from ever achieving a 100% rust browser.

Re: A future for SQL on the web

#142

Post by quickthrower2 »

Reading Mozilla docs I get the impression that your data could get nuked in indexdb if it needs to clear space.

Attack vector might be to register 1000 domains then get a page to load each of those to fill up its 2Gb quota? Just guessing….

Re: A future for SQL on the web

#143

Post by ciex »

lioeters wrote: post #32

> browsers may delete your IndexedDB database under certain conditions Safari will happily delete your IndexedDB database after 7 days of inactivity. It deletes "all of a website’s script-writable storage after seven days of Safari use without user interaction on the site". That includes: - Indexed DB - LocalStorage - Media keys - SessionStorage - Service Worker registrations and cache Source: https://webkit.org/blog…

But doesn't this 7 day limit only apply if you load a third party script that uses IndexedDB into your site?

Webkit says in your source:

> It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.

Re: A future for SQL on the web

#144

Post by gunapologist99 »

EvanAnderson wrote: post #4

This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…

> It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale").

This is almost certainly not even close to correct. There are substantial reasons why it wouldn't be a good idea, but this might be the biggest one: it's very hard to adequately sandbox an external C library.

(... and, also, Apple probably would prefer that the web didn't exist at all, but that's a different pandora's box...)

Re: A future for SQL on the web

#145

Post by rattray »

stevage wrote: post #132

Fascinating. I'm really curious what the use case is that so many people seem to have. Why do you need so much data in the browser, and to be doing queries and data manipulation there? Where does the data come from? Don't you need to sync it back to a server somewhere?

This lets you write any Serious App with "single-player data" as offline-first (though yes you still need to handle syncing to the cloud somehow – jlongster has done some very cool stuff for that too, looking forward to him sharing more about that).

Re: A future for SQL on the web

#146

Post by guyromm »

breckenedge wrote: post #138
guyromm wrote: post #103

i wonder if it's possible to plug any kind of streaming replication onto this. i don't have much sqlite experience, but maybe someone here has an idea if it would be possible to run litestream or something of the sort, as both master and slave - in the browser. that would solve the safari indexeddb 7 day ttl issue to start with. and if replication could be made to work on top of something like webrtc we're looking at…

There’s also CouchDB/PouchDB made for this use case.

that one i did take for a spin.

i must say that the experience is quite horrible - that torture of having to write map/reduce functions, added with some erratic behavior in regards to data integrity (inserted entries silently discarded, sync to the remote couchdb instance working somewhat whimsically). as soon as your dataset is sizable in any regard (tens of thousands of records in a collection, if i recall the terminology) it begins to just break apart.

was writing a browser extension, and used pouch with the hope of keeping its persistence local and avoid needing a server. seeing that it leaks tried to trade it for a couchdb server. seeing how bad sync is, and that couch is not very comfortable to work with either ended up throwing the thing in favor of a postgresql+postgrest backend.

Re: A future for SQL on the web

#147

Post by qwerty456127 »

EvanAnderson wrote: post #4

This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…

> It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale").

Whenever I need simple (but indexed) key-value (unless that's a hi-load server-side) I always just use SQLite anyway. I really don't understand why do we need any data storage other than SQLite (and HDF5 perhaps) to exist on the client side.

Re: A future for SQL on the web

#148

Post by Cyberdog »

gunapologist99 wrote: post #141
EvanAnderson wrote: post #4

This is funny and sad to me. We had SQLite in the browser[0]. I only did a little bit of work with it but it seemed actually pretty nice. It was torpedoed because it was SQL-based (and not trendy "key value" and "web scale"). There was the whole excuse that the specification was "whatever SQLite does" and, therefore, not suitable for being a standard. There would be worse things than SQLite upon which to base a stand…

Another, probably not insurmountable, issue with SQLite in the browser (without having a formal specification that could produce cross-language alternatives): Using SQLite results in a new, built-in reliance on a C library. Even though most languages can use C library bindings, it does present some issues in some build scenarios, such as static builds, and, given the enormous scope of SQLite, would prevent anyone fro…

I find this an odd comment. Is a 100% Rust browser something anyone is clamoring for?

At any rate, if that really is your goal for some reason, rendering engine is going to be your first problem anyway. Then a JS runtime.

Re: A future for SQL on the web

#149

Post by andai »

hitekker wrote: post #31
daleharvey wrote: post #10

Earlier quoted context omitted.

The excuse was that a standard needs to have multiple implementations otherwise we are standardising implementation details and bugs. Hindsight shows that was entirely correct, as SQLite bugs were then found that could be exploited directly via WebSQL, Firefox of course was not vunerable. ( https://hub.packtpub.com/an-sqlite-magellan-rce-vulnerabilit... ) As a sidenote, I worked a lot with the WebSQL API and it was n…

I view the "standards" argument as a red herring for building a NoSQL db in the browser. Which, to this day, is slow, buggy and requires third party libraries to be usable [1] For those who are able to stomach an uncomfortable political history instead of an easy, technical answer, you can take a look at [2]. It's interesting that 7 years later, many the folks who pushed hard to get rid of SQL in favor of NoSQL seem…

PROLOGUE

Six houses, all alike in dignity, In fair IRC, where we lay our scene, From ancient grudge to new mutiny, Where civil blood makes civil hands unclean. From Oracle, that SQL seer of IndexedDB, To Google, the stronghold of search, We add Mozilla, the Web SQL killa, And Apple, peering from its mobile perch. Here, a storage war would set keys to clack, Tongues to wag, and specs to shatter, There was also Microsoft and Opera, Who don't really seem to matter.

THE PLAYERS

NIKUNJ MEHTA, of House ORACLE, an instigator JONAS SICKING, of House MOZILLA, an assassin MACIEJ STACHOWIAK, of House APPLE, a pugilist IAN FETTE, of House GOOGLE, a pleader CHARLES MCCATHIENEVILE, of House OPERA, a peacemaker

ACT 1

SCENE: A dark and gloomy day in Mountain View, or perhaps a bright and cheery one, depending on your IRC client's color scheme.

Re: A future for SQL on the web

#150

Post by smackeyacky »

regularfry wrote: post #91
411111111111111 wrote: post #62

Earlier quoted context omitted.

What gives you the confidence that it's going on circles? I cannot see our industry repeating the mantra that NoSQL solves all our persistence problems ever again. There are use cases for them, but not everything is a good fit and I'm pretty sure we found that out as an industry. I'm sure there are always going to be individuals that will claim that they're better at everything, but that doesn't really mean anything.…

The cycles are longer than you're imagining. Relational database folk have been railing against the incursions of one generation of non-relational database type or another since at least the 1980's.

Actually, relational databases are the relative newcomers. The limitations of things like CODASYL were well known to 1960s programmers and Codd's relational model sought to address them.

Why the non-relational databases keep getting reinvented has been a bit of a mystery when there is already a rich history of development to look to. I get the feeling a lot of the industry isn't much into history, especially of pre-micro computer systems.

Network databases, key-value stores, graph databases, commercial offerings like Pick... you'd think the NoSQL people would have looked into it all before proclaiming their new found solutions, but apparently not.

Post reply on HN