v21’s avatarv21’s Twitter Archive—№ 77,247

      1. deciding to use SQLite as the backend database for Downpour & it's really freeing to write server code knowing reading from the database isn't going to have the kind of latency that comes from fetching stuff over the network
    1. …in reply to @v21
      "200 SQL statements per webpage is excessive for client/server database engines like MySQL, PostgreSQL, or SQL Server. But with SQLite, 200 or more SQL statement per webpage is not a problem." sqlite.org/np1queryprob.html
  1. …in reply to @v21
    especially since I'm building it to talk GraphQL, which allows you to minimise sequential calls client <=> server, but at the cost of sometimes generating a lot of sequential database calls on the server.
    1. …in reply to @v21
      or like. the client passes in a JWT, and I could either trust it as is or go look it up in the database, see if it's been invalidated or not. with a client-server setup, I'd not want an extra query's worth of latency in there. With SQLite, sure, why not, it's a cheap query.
      1. …in reply to @v21
        as i was saying! (Litestream seems great, planning on using it once I get to the bit where I actually deploy this stuff) fly.io/blog/all-in-on-sqlite-litestream/
        1. …in reply to @v21
          i'm setting myself the made up rule that, just like making videogames, everything has to happen within 16ms.
          1. …in reply to @v21
            also! I know this is not unique to SQLite, but JSON support is really neat. just put it in the database as text and then add some columns and views adding indexes to it.