POC: UserStorage

We've had engineers that don't love the way that we are currently storing user data in Atlantis because it can be cumbersome to extend, so it was briefly explored to do this in a different way, but ultimately decided to not implement right now (mainly due to wanting to migrate existing user data to this new system, so we didn't have 2 systems doing the same thing to maintain), though I will detail the idea as it may be something we want to look at doing in the future.

Key Value Pairs

We wanted a solution that would not require us to update the backend whenever we wanted to store a new value (like the date they went through a tour for some feature). Our idea was basically browser local storage that persisted across sessions and devices. The backend would authenticate the user, but would not validate the keys or values (or at least very minimally, like length of value perhaps) that were set or read. There would be basically two endpoints, one to set a value, and another to read a set of values.

Azure Table Storage

We thought through the access patterns for user data, and we saw no issue we exclusively limiting data to be read by user id and the key of these key value pairs, which made azure table storage seem like a great fit. We planned to create a new Azure Storage Account to store user data and use Azure Table Storage to have a table for each user in the system. The table would simply consist of rows that were the key value pairs of data, rather than storing a big json document with every property we ever cared about related to user data, and making sure all those properties were set correctly every time the document was updated.

POC

Though we didn't totally flush out the POC, we did write some code to start flushing out the idea and the branch is named POC-NewUserStorageSolution, and most all of the added code was put in a new module called UserStorage.