June 18, 2024

• native columns instead of ‘data’ json columns

  • [s] sounds very involved
  • [i] we want the json blob!
    • [J] Agree it makes sense for contracts / users
      • But also I think it would be better for contracts to native columns
    • [i] I think it makes sense to move more attributes out of the data column, but not eliminate it entirely
  • [J] Getting bets off data column is a big deal IMO
    • [s] bets in particular seems very worthwhile

• [x] migrate firebase scheduled functions to scheduler

  • [s ,i] do we need to do this?
  • [s] how difficult is this?
    • [J, c] Easy

• migrate iaps and stripe-purchases

  • [s] this should be easy, and means we can stop using firestore entirely on backend

• [x] [c] fully deprecate private groups

  • [s] long overdue. probably should just delete them
    • [i] Bad for accounting. Just delete comments, clear description, title, and slug

• [x] Websockets for user updates (eliminate polling)

• Look into supabase migrations tooling

  • [mqp] Note that doing this will have the side benefit that the schema is written down in a way that lets anyone easily spin up a new database. That means that self-hosting, one-off dev test databases, and automated testing gets much easier. So I would highly suggest it

• [x] Check the bundle to see if most of firebase dependency is tree-shook

• Test point in time recovery on dev db

• [J] Endpoint to drizzle that the scheduler calls

  • and using queue
  • [s] we should do this

• dedenormalize user data, pass through static props

• [x] Formatting of sql?

• Foreign keys, other postrgres constraints like positive numbers, non-null

• Trim down columns we don't need

  • Delete denormalized username, userAvatarUrl, visibility

• Avatar url is dependent only on user id

• Switch auth to custom solution

  • Gets us off firebase entirely
    • [s, i] this doesn’t seem like a priority now
  • We need to implement email/password auth anyway for business reasons

• dev experience

  • make builds faster
    • [mqp] Based on my experience I continue to suspect you guys should try to get more RAM on your boxes. Not sure though
      • [c] i want to be able to work from the beach with my macbook air, fite me
      • [J] I got a new laptop and it’s still not that fast
  • Auto-refresh is too slow
    • try vite? or js build? or turbopack again?
    • [s] this is important
  • api server reloading takes a while, and next throws errors if it loads in the page before the server is ready
    • [mqp] This reloading can probably be extremely optimized. The most obvious thing that would make it faster is that right now the API server reloading is just “rebuild everything when anything changes”, and the rebuild is expressed as a bunch of chained yarn commands, which have lots of overhead. If they just changed into a shell script and nothing else I bet it would be a perceptible improvement. You could also do obviously less work by doing stuff like “run tsc-alias only on the project that changed.”
  • Local supabase database for dev testing
    • or cloud dev databases for everyone
    • and move dev server into the cloud?
    • [c] i tried supabase’s migrations tooling. i could see the benefits of it and it seemed … fine, but i don’t think we need it yet