3 ms·

I love it and will give it a go! I'm also intrigued by your 'SQLite-per-user' structure and would be keen to hear how you get on with that long-term. For insta

• bradleyjkemp 6y ago
  I'm planning on a Stripe-style approach where each user (perhaps even each access token) can choose which version of the database schema they want to query. I don't have any worries about managing long-term schema migrations though because the per-user databases get blown away and reconstructed every time the calendars are refreshed. At the moment there's just an `events` table but I might handle migrations by having: `events_v1`, `events_v2`, etc. and just have `events` be an SQL view onto the version you chose. Managing as little persistent state myself was a specific goal so this project is perfect because apart from some authentication info and a list of iCal URLs, the source of truth for your calendar is always with Google/Microsoft/etc.
  • simonhamp 6y ago
    Sounds ideal. I really like the isolation of separate DB files per user. In more complex systems though it feels like it's going to require quite a bit of orchestration. The big option that SQLite opens up though is portability - I imagine one day just saying to customers that they can download their database and interface with it themselves or shift it to another provider.