Data Storage Proof Of Concept

[jjm3x3]

The parameters for this are fairly open-ended, at the moment. As a result of this POC I am expecting that we have a much more solid idea of what kind of backend storage we plan to use and that can probably come about several ways. Playing around with and trying a couple of different options is one and coming up with a one-pager or decision doc explaining an approach is likely the most sensible outcome.

[jjm3x3]

Just right off the top of my head I am wondering if this entire milestone should be broken up in a couple of different ways (these are in no particular order for now):

• Get existing user data out of source code and into a db
  • Need to make sure we have db backups happening before we remove existing data from src
  • Need to also to consider how we upload new data here since currently this is all done by checking into git
• Building competing entity data
• Updating the "front end" to pull from back-end (does this include being able to pull from both)
  • Add a ability to pull form both

[jjm3x3]

Also, one other thing I am going to put out there right off the bat is that I likely have a bit of a bias towards trying to use something that requires as little overhead to use as possible. Off the bat, that seems like it could look like Vercel KV, but that could be too lean and could cause us to do more work in the long run, so that is one focus of this POC.

[jjm3x3]

Work Check In

Approach/Goal

Using this comment's list to guide this work I have started to take a look at what the simplest way to add a leagueContestant to a Vercel KV Database might be.

Learnings

It seems like Vercel's KV Database offering is very simple to get stared with including its quickstart guide. It also seems to be quite compatible with the default Redis as described in this doc of theirs. A few interesting details to note

• It seems like the offering is actually backed by a Upstash so Vercel's KV library is pretty much a wrapper around ustash's redis lib
• Redis and subsequently Vercel supports storing json objects using the JSON.* set of commands
• The SCAN command seems like the right way to grab a related set of leagueContestant data based on league
• One workable idea for a key is something like show:season:userId where show & season are exactly what you expect and userId can just be a monotonically increasing id (ex: amazing-race:35:1)
  • Keeping in mind this means that leagueContestants or user's data will not be related across leagues)

Open Questions

Here are a few open questions that we should try to get answers to

• While trying to get a lil demo or poof of concept working the command npm run build running locally, seemed to fail because the secrets were not available. These seems to indicate to me that these pages are trying to access the KV Database for static site generation. Is that true?
• Hand in hand with the previous question what does the dev experience look like after adding this dependency. If we are limited in the number of seats we can have on Vercel can others even pull those secrets?
• How do we backup or take snapshots (this is covered in one of the initial bullet points) edit: just found this doc on backup
• Still not sure how to get the user data uploaded (depending on how quickly we can get into inserting it from the site, we may not need to formalize this process)
  • note: For this POC, I created a lil /api/install endpoint which adds data for testing (in combination with Vercel's cli tool int the project portal)