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

31–40 of 227 posts

Re: A future for SQL on the web

#31

Post by hitekker »

daleharvey wrote: post #10
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…

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 to no longer occupy positions of prominence in the industry.

[1] https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...

[2] https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...

Re: A future for SQL on the web

#32

Post by lioeters »

> 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/10218/full-third-party-cookie-blocki...

Found via: The pain and anguish of using IndexedDB: problems, bugs and oddities - https://gist.github.com/pesterhazy/4de96193af89a6dd5ce682ce2...

Re: A future for SQL on the web

#33

Post by kwhitefoot »

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…

> not trendy "key value"

You can put anything in an SQLite record so it can certainly be used as a key-value table. Where at least the values can be arbitrary binary blobs.

Re: A future for SQL on the web

#34

Post by ghostbrainalpha »

short_sells_poo wrote: post #29
CraftThatBlock wrote: post #25

Earlier quoted context omitted.

Not enough blockchain! Needs more Web 4.0

Came here just to say this. Each SQL program needs to run on a blockchain so that there's no central authority that can unduly influence the data.

I legitimately can no longer tell if this was being suggested sarcastically, or if you guys are being serious.

Re: A future for SQL on the web

#35

Post by westurner »

leros wrote: post #6
timdorr wrote: post #2

What's kind of bonkers here is that IndexedDB uses sqlite as its backend. So, this is sqlite (WASM) -> IndexedDB -> sqlite (native). The Internet is a wild place...

I'm going to build a business that offers SQLite as a web service. It will be backed by a P2P network of browser instances storing data in IndexedDB. Taking investment now.

TIL, about Graph "Protocol for building decentralized applications quickly on Ethereum" https://github.com/graphprotocol

https://thegraph.com/docs/indexing

> Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn from a Rebate Pool that is shared with all network contributors proportional to their work, following the Cobbs-Douglas Rebate Function.

> GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers can also be delegated stake from Delegators, to contribute to the network.

> Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.

It's Ethereum though, so it's LevelDB, not SQLite on IndexedDB on SQLite.

Re: A future for SQL on the web

#37

Post by ampdepolymerase »

leros wrote: post #6
timdorr wrote: post #2

What's kind of bonkers here is that IndexedDB uses sqlite as its backend. So, this is sqlite (WASM) -> IndexedDB -> sqlite (native). The Internet is a wild place...

I'm going to build a business that offers SQLite as a web service. It will be backed by a P2P network of browser instances storing data in IndexedDB. Taking investment now.

This could actually work for certificate attestation if baked directly into the browser.

https://github.com/google/certificate-transparency

Re: A future for SQL on the web

#38

Post by otabdeveloper4 »

kall wrote: post #13
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…

The sad irony is that if HN is anything to go by, SQLite is super trendy now. I feel like "just sqlite" was really a very practical idea and now, because it has already failed once, we can‘t really try it again, or can we? Having the spec basically be "bundle one particular piece of software into the browser" might not be in the spirit of web standards, but on the other hand SQLite is so widely bundled into everythin…

There's no such thing as "the SQLite" that you could even theoretically bundle.

Which version do you want to bundle? With which compile flags and which extensions? Do you have a checklist for bug-for-bug compatibility? Because you'll definitely need one when a future SQLite releases a security patch and breaks a million webpages.

Re: A future for SQL on the web

#39

Post by lovasoa »

eatonphil wrote: post #14

sql.js is pretty hard to use as is otherwise you run out of memory really quickly. I was trying to use it as the in-memory SQL flavor for an open source data ide [0] but my naive approach of `SELECT * FROM VALUES (...), ...` would run out of memory after only a few hundred rows. I ended up switching to https://github.com/agershun/alasql which could handle up to 80MB of data or so. (I haven't yet tested on larger data…

When did you make your tests, and with which browser ? Did you use a prepared statement to fetch your results ?

Raw sql.js is limited by the browser's wasm memory limit, but 80Mb should not cause an issue...

Re: A future for SQL on the web

#40

Post by daleharvey »

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…

I am familiar with Nolans article, I created PouchDB (the project he is discussing), you seem to have misred the post as it discusses the technical nuance and tradeoffs involved in the decision at many points entirely agreeing with the position against WebSQL. While Nolan came to the a different conclusion than I did (a point he made in the post) he laid out challenges very well and made it very clear there was no obvious technical answer.

Regardless of how you view it, the benefit of hindsight shows the exact thing that people warned would happen did in fact happen (a widespread venerability in SQLite exposed across various browsers). Its also a fairly strange point to be personally insulting people involved in the process whose careers are doing perfectly well.

Post reply on HN