Add Backups/Remote Storage

[royanger]

The biggest concern/question I have about features like Issue 220 is that lack of backup options. IE, if there is a calendar and Todos and Notes (and maybe more in the future) all of that data is linked to the computer+browser (local storage). A user couldn't access this data on a phone too, or another computer. They could also lose it via clearing data for the browser, computer crashed, etc.

This has got me thinking about how we could tackle this problem with no disruption to the current app. I have a rough plan in mind, one that will need discussion on whether this should even be considered and if so what should the final details look like.

Goals

• no login wall/auth requirement to use
• all data should be loaded from Local Storage initially and we should not have the typical loading states we see with frontend+backend coupling (the exception can be things like the Hacker News widget which has to load data from a 3rd party)
• backup data to API/remote storage

Challenges

• protection of user data -- the user may include Todo, Note, etc, information that is sensitive in nature. Do we encrypt that data in the DB/on the remote storage?

Plan

• implement auth with Passport JS or maybe Clerk.dev. This should result in little to no obvious change to the tool for users, and no need to swap to Next/ etc.
• Add Google GitHub and Twitter as a login options
• use a relatively long lived session to minimize logins (this is up for debate)
• connect backend api to either a cloud based DB (Cockroach/Planetscale/Railway) or remote storage (S3/D2) to store user information
• whenever user makes a change to items in the app, the data sent to the backend
• restoring? should the api just quietly update the local data with remote data if the item(s) are missing from local? should there be a 'restore data' that does the restore on command? should the restore data bata merge remote and local data or remove local and replace with remote?

[mastermajorman]

@Melkeydev had developed a pretty large backend in Go a bit ago. I forget exactly how much of it was done by scratch or with third-party components, but I want to say it was substantially original. I think we decided not to implement it long-term because it was a lot to maintain and pay for with little upside. However, as grow Astrostation we can probably manage a low cost server (<$2 month), so might be worth checking this out again.

I'm all for reducing the opportunity of user headaches as the widgets we're adding become more personalized and depended on. Perhaps taking the lightest serverless approach possible (as I think you're describing) would be an ideal route. We could set up a few services with AWS to accomplish this. IAM+Cognito for authentication and authorization, then either API Gateway+Lamba+S3 or EC2+S3 for storing and retrieving user data. I've got some experience in this arena if we decide to take this on.