Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • nice pattern with the stored queries for writes. but who defines them? if the app author can create their own stored queries, the write restriction is basically honor system.
  • There are actually two types of stored query: regular and "trusted".

    Any query you save is a regular query. It operates under the permissions of the viewer, and checks that the viewer has the necessary permissions - read access to the database, or more finely grained write access which checks the individual tables they will be writing to.

    The problem with that is that it means you can't build an app which other, signed out or unprivileged users, can use.

    So there's a second category: "trusted" queries. These are current only configurable by the site administrator who controls the Datasette deployment, as they go straight in the configuration file: https://docs.datasette.io/en/latest/sql_queries.html#trusted...

    I'm planning to add a way for trusted users to create these through the UI via another permission, with a very strong UI warning to only use this feature if you understand the implications.

    Here's a demo of an app that runs against trusted stored queries: https://agent.datasette.io/-/apps/01ktw6fpag19dnnga85t2ced3p

    Source code here, showing how those queries are called: https://gist.github.com/simonw/6e6a3760fa0528ceda1f65d789069...

    It uses these queries: https://agent.datasette.io/content/timeline-filtered and https://agent.datasette.io/content/timeline-count

  • How does this work, does some mechanism replace the actual tape drive in the Datasette? Can you just use the tape port with the gadget or does it somehow need the tape drive? How do you access the HTML applications, how is the translation to PETSCII handled?

    I have no idea how this could work but as a long time Commodore 64 fan I'm interested. The link won't load for me, sadly. Can somebody give me a quick rundown on how I can host HTML apps inside my Commodore Datasette tape drive?

  • I didn't quite get the CSP part. Why use and srcdoc and <meta http-equiv="Content-Security-Policy"> instead of a real server header? Static hosting?
    by est
  • If you host iframe apps at a fixed URL like:

      /-/apps/iframe-content/timeline.html
    
    You can protect it with CSP headers, but you can't also protect it with the sandbox="" attribute (should a user visit it directly)

    If you want both sandbox= restrictions and CSP headers at the same time the only way I've found that works cross all major borders is the iframe plus srcdoc="" with injected CSP meta headers patterns.

    Note that a lot of sandbox implementations serve their iframe content from a separate domain, to ensure cookies and localStorage and other same origin things are robustly protected.

    I can't do that easily for Datasette because it's open source software that people can run on their own laptops, so I didn't want to block people on "now register a domain/subdomain and set this up in DNS".

  • Hey Simon,

    although I'm coming from a different starting point, it seems like some of our thoughts have aligned. I'm building https://caipi.ai/ as a workspace for agents to build simple data driven apps. The agent edits through MCP and the user gets an interactive app in the browser.

    If you're interested picking each others brains around this topic, I'd be psyched to have a chat. gh:pietz.

  • Looks like a good addition to the datasette ecosystem. I have been working on a similar idea with cusom html around sqlite databases. By default a faceted search interface is generated but by reusing the client side data layer, custom apps are made easy.

    The design keeps data and presentation together and even maps do not rely on external services.

    I have called it Pihka: https://ghentcdh.github.io/Pihka/ https://github.com/GhentCDH/Pihka

  • From TFA:

    > a Datasette-style backend to a self-contained HTML frontend is an astonishingly powerful combination.

    1000% agree. And datasette is a terrific framework to build any kind of data exploration or visualization on.

    This sounds like an awesome feature and a good excuse for me to dive back into playing with Datasette.

  • I never understood why someone hasn't made a framework that makes it stupidly easy to fill an HTML page with SQLite database tables, with all the usual display controls, and with as much "liveness" as desired, and with a protocol (over HTTPS) to manage comms to a server-side instance. SQLite is robust, lightweight, bulletproof - a WASM build belongs on ALL the webpages !
  • Like MS Access on web?
  • It's not specific to SQLlite per se, but that's what most dashboard builders are
  • Something like sync engines? I think there are a bunch nowadays.

    https://syntax.fm/show/924/sync-engines-and-local-data

  • Because it's pretty much worthless.

    You almost never need just a basic list of all the data in your table, even if you're able to filter and sort it. There's no moat there at all. People need serious BI tools, and that throws simplicity out of the window (PowerBI, QuickSight, etc.).

  • Did you have a look at https://evidence.dev
  • As mentioned below I have been building the 'read' side of this: a data publication platform. I wanted to avoid any server side components. The communication / write part and updating the server-side sqlite database would need running components on the server which I wanted to avoid.

    The 'write' part would technically be very doable and not that different from other back-ends.

    https://github.com/GhentCDH/Pihka

  • It is pretty cool that we have browser features like this to rely on.

    I remember writing code in the bad old days to parse HTML tags and allowlist specific attributes. Now browsers have a much better solution baked in.

    But it still makes me a bit nervous. Seems like a very small bug could sneak in. This is a good example of where I would reach for Fable to double check the implementation and have a lot of extra tests.

    (nit: would be nice if the chat box treated Enter and Shift+Enter the way these other companies have trained my brain, but maybe that is a deliberate choice.)

  • In the three short days we had access to Fable I did have it run a review, and it spotted an issue for me to fix.

    Thankfully GPT-5.5 is really strong on security stuff too. I wouldn't have dared build this without a whole lot of Opus/GPT-assisted prototyping and testing along the way.

  • Multiple projects are coming to the same point it seems. Motherduck has been marketing "dives" since the beginning of the year (https://motherduck.com/blog/duck-dive-and-answer/) and in the Louie.ai team, we have been iterating on different patterns for similar needs. I'm getting the feeling that the answer to SaaS apps as fixed UIs over databases being dead because of coding agents means just the fixed dashboard pattern is dead, not SaaS, and BYO UI is part of the new table stakes.

    I'm curious where the pattern will go. My sense is there is a split between cathedrals vs bazaar for approach here, where cathedrals are quite rigid app builders, think framer/wix, while bazaars focus a layer below for more flexibility but less integrated.

  • At the enterprise level this feels a lot like Snowflake buying StreamLit to try and have a similar experience, and keep you in the Snowflake ecosystem burning credits.
  • Absolutely, plus if you control the coding agent you can enforce certain guarantees and have it wrap your services with a custom sdk. I've been exploring this pattern in a couple of different domains where it's just a vite react app wrapped in an iframe with a JWT bridge giving auth, hosted on a separate domain.
  • When I've needed something like this in the past I've spun up simple HTML pages and used the json endpoint that all datasette instances come with [0]. I like this new pattern much better, as it keeps your app and data in one place (I remember having some issue with this at the time, though I can't remember what the actual issue was)

    So I imagine we could now load some data in to sqlite, design some HTML also loaded in to the db, and deploy. Although looking at the source, it seems like stored apps are expected to be managed by the plugin itself, but I'm sure there's a way around that

    [0] Eg from one of the examples - https://datasette.io/legislators/-/query.json?sql=select+*+f... . If you strip the '.json' you get the html view. For what it's worth there's also a '.csv' version.

  • This seems to attractive side of seeing it, however the striping Json would not be suitable i believe
  • > it keeps your app and data in one place (I remember having some issue with this at the time, though I can't remember what the actual issue was)

    CORS headers?

    by e12e
  • I'm going to think about how Datasette Apps can work with the apps themselves stored on a filesystem so they can be revision controlled using Git.

    I have an idea for a way to edit them through Datasette and have them backed up to Git via a separate mechanism, but having them on disk would be a whole lot more convenient.

    Filed an issue here: https://github.com/datasette/datasette-apps/issues/30

  • To save anyone else wondering what is Datasette a search:

    “Datasette is a tool for exploring and publishing data. It helps people take data of any shape, analyze and explore it, and publish it as an interactive website and accompanying API.

    Datasette is aimed at data journalists, museum curators, archivists, local governments, scientists, researchers and anyone else who has data that they wish to share with the world. It is part of a wider ecosystem of 44 tools and 154 plugins dedicated to making working with structured data as productive as possible.”

  • I’ve been using the Observable Framework[1] for this kind of work but it doesn’t appear to be actively developed anymore so will look into Datasette.

    [1] https://github.com/observablehq/framework