Oh wow, I wrote this way back near the start of the project. I've been planning to write an updated version, and maybe incorporate that into Datasette's official documentation.
Most of the ideas in there are still used by the core project, with the exception of one: the "Far-future cache expiration" item.
That's the thing where Datasette rewrites the URL to incorporate a hash of the database contents, then serves them up with far-future cache expiry headers.
That 2018 blog entry also talks about " Bundling the data with the code" - I've since expanded that idea into something I call the "Baked Data" architectural pattern: https://simonwillison.net/2021/Jul/28/baked-data/
I use datasette almost daily (thanks simonw!) for ad-hoc queries and for validataion.
Often I'll have two APIs from different systems, which I may or may not have access to directly. Typically I'll need to denormalise the data and dump it to some csvs, use csvs-to-sqlite (from the datasette ecosystem) to convert to a db and open up datasette. I've discovered errors that had remained hidden for months (different teams etc etc) using this workflow.
Also, because the queries are url-encoded I'm considering using it as a 'fake' backend for some proof-of-concepts backed by a couple of cron jobs running the pipeline
I don't get Datasette. I had a small dataset I wanted to use with it, hoping it would be some sort of moderately advanced FOSS BI software, but all it did was give me a table view.
In terms of use-cases: I've recently started asking people who use it what job they hired it to do. One of the leading answers is for data publishing - they use it as a tool to quickly publish data online for others to use:
Thanks for replying, Simon! I guess my use case was a bit of a toy, I don't have a huge dataset to use facets on, I basically just made a small spreadsheet of blood tests and wanted to see if I could easily navigate the data better than what Excel did. I did install Vega, but it had basically one way to display data (I didn't look into it too much, though).
I think my use case was just not suitable for it, from your answer I guess it's more for people who have huge datasets they want to publish. I imagine it will be much better suited for that purpose, though I tried the demo a few times and couldn't really think of any interesting questions to ask it, so I didn't get it there either...
Datasette is one of those things that sounds very promising, so I want to explore it, but I end up walking away every time. It just sounds like it's not for me, though.
Maybe it would be interesting to replace Sqlite with DuckDB, since both of them are in-process databases, but Sqlite is OLTP and DuckDB is OLAP. I wager most interesting queries will be better served by an OLAP database, like facets: https://simonwillison.net/2018/May/20/datasette-facets/
Most of the ideas in there are still used by the core project, with the exception of one: the "Far-future cache expiration" item.
That's the thing where Datasette rewrites the URL to incorporate a hash of the database contents, then serves them up with far-future cache expiry headers.
It used to be default behaviour, but I changed that when Datasette started allowing plugins to make writes to databases in February 2020 https://simonwillison.net/2020/Feb/26/weeknotes-datasette-wr...
A few weeks ago I removed the remains of that feature from core entirely, and instead made made it available in a Datasette plugin: https://datasette.io/plugins/datasette-hashed-urls
That 2018 blog entry also talks about " Bundling the data with the code" - I've since expanded that idea into something I call the "Baked Data" architectural pattern: https://simonwillison.net/2021/Jul/28/baked-data/