Live data from Hacker News

Hosting SQLite Databases on GitHub Pages

phiresky.netlify.app

31–40 of 82 posts

Re: Hosting SQLite Databases on GitHub Pages

#31
post #23

I can’t fully put my finger on why exactly, but I feel that this is a transformative idea. What’s to stop me from emulating a private SQLite DB for every user of a web app, and use that instead of GraphQL?

I have software deployed that depends on locally run (MySQL) DBs sitting on user/retail outlet machines, and I could think of a few reasons. Big data downloads, modifying anything about the data structure can cause breakage between the middleware and the DB, you're basically distributing a data model along with what should normally be serverside code to the client. Conceptually it's great but for large data, I'd hate to be paying for the bandwidth if it were public. And if it's not just a web page, you need a way to update it on every platform. Also, there are always things in a web app that simply cannot be client-side because they'd pose a security threat.

The concept reminds me a little bit of CD-ROM multimedia, in that it's so self-contained. For something like that it's great.

Re: Hosting SQLite Databases on GitHub Pages

#32

bummer on not being able to write to sqlite. I am using neocities and was wonder how i could get a db into play

Depending on how often you need to write, you could use a CI pipeline on a cron to collect your updates, add them to a the sqlite file and commit the changes.

Re: Hosting SQLite Databases on GitHub Pages

#33
post #27

Earlier quoted context omitted.

You actually can use SQLite on some browsers with WebSQL today. Unfortunately, WebSQL has been deprecated and is already removed from some browsers ( https://softwareengineering.stackexchange.com/questions/2202... ).

Oh man, that's a shame. I remember looking into WebSQL when I was designing a little Phonegap tourist app, and ended up just using localstorage instead, like this guy, but I tucked it away as a possible technology for some use case I never quite got around to. SQLite is great and it doesn't make any sense to deprecate WebSQL in favor of some key/value "nosql db" pattern, since there are already plenty of other altern…

It was deprecated because it was difficult to write a standard spec for the existing SQLite code (but a key value system is much easier to specify as there is no SQL language).

Re: Hosting SQLite Databases on GitHub Pages

#34
post #4

Earlier quoted context omitted.

Yeah it's sad apple has crippled their browser the browser on a $40 android tablet is more powerful than safari running on a $1200 iPhone

There’s a market for both devices, and justifiably so. Why not celebrate the fact that people have a choice?

separate from this, one of those devices is slowing the web from fully transitioning back to webapps.

Re: Hosting SQLite Databases on GitHub Pages

#35
post #23

I can’t fully put my finger on why exactly, but I feel that this is a transformative idea. What’s to stop me from emulating a private SQLite DB for every user of a web app, and use that instead of GraphQL?

IMHO this reduces the need for a full fledged database serving read only information at scale. The restriction before this is that a SQLite file had to be on a single server. Now, having SQLite on S3, you could write a set of scalable web services on top of the file on S3 and scale those services as much as needed.

Re: Hosting SQLite Databases on GitHub Pages

#36

Earlier quoted context omitted.

Oh man, that's a shame. I remember looking into WebSQL when I was designing a little Phonegap tourist app, and ended up just using localstorage instead, like this guy, but I tucked it away as a possible technology for some use case I never quite got around to. SQLite is great and it doesn't make any sense to deprecate WebSQL in favor of some key/value "nosql db" pattern, since there are already plenty of other altern…

It was deprecated because it was difficult to write a standard spec for the existing SQLite code (but a key value system is much easier to specify as there is no SQL language).

Yeah but a key value system lacks all the really good things about SQL. And locally with sqlite you don't really have to worry about latency, so you should be able to just get atomicity and consistency on the thread. This shouldn't be a lot to ask from an embedded web DB. I think as with other standards bickering, ten years from now something (Canvas API) will come out that more or less replicates the technology that was already standard ten years ago (Flash graphics), with lots of people cheering for it as if someone just invented sliced bread.

Re: Hosting SQLite Databases on GitHub Pages

#37
post #23

I can’t fully put my finger on why exactly, but I feel that this is a transformative idea. What’s to stop me from emulating a private SQLite DB for every user of a web app, and use that instead of GraphQL?

Yes, I was just thinking the same thing. It would be very interesting to skip GraphQL altogether using this alongside RESTful APIs.

Re: Hosting SQLite Databases on GitHub Pages

#38
post #23

I can’t fully put my finger on why exactly, but I feel that this is a transformative idea. What’s to stop me from emulating a private SQLite DB for every user of a web app, and use that instead of GraphQL?

Nothing stopping you doing that right now with localStorage or IndexedDB. The issue is the browser cannot be trusted to keep that data, or at least these APIs aren't designed for long-term persistent storage. If we could solve this problem, we could go a long way towards some level of decentralisation. On the other hand, which is more secure? Your service or the user's machine. So there's a lot to consider.

Re: Hosting SQLite Databases on GitHub Pages

#40
FWIW the scientific computing community (who often deal with petabytes of geodata) has been thinking of ideas like this for a while, e.g. techniques around file formats that are easy to lazily and partially parse, (ab)using FUSE to do partial reads using http RANGE requests, some combination thereof, etc:

http://matthewrocklin.com/blog/work/2018/02/06/hdf-in-the-cl...

Post reply on HN