Self Reflect: Part 1 - How to start and general motivation.
Tags: selfreflect
Published: 2021-05-28 14:14:38

As a project like this matures, the real architecture challenges will be around data. The frontend (or frontends) will likely be the easiest places to overhaul.
The question of associating question responses to user or to questions with user as a foreign key is a big one.
Running slow operations to recalculate aggregate results is something that could be manageable early on.
Because the initial focus should (and perhaps always) be on the individuals historical trends, the JSON structure above is enough of an approximation to get us looking for implementation options.

In fact, the most important thing to always have in mind is a user, a user story, or a piece of functionality. In this case, the POC user will be me. Something I can use to begin tracking my days.

That puts us squarely in tech selection mode. In a normal enterprise setting, we'd spend oodles more time on architecture and design and selection. But when you're trying out an idea on your own, where the pressures of real life are constantly nipping at your heals, doing and redoing is much better than planning. Why? Because inertia matters. In a corporate environment, there will be cogs in motion keeping projects moving forward even when interest, enthusiasm, or progress wanes, but at home, if there's not something constantly just within reach, it's very easy to start looking at the next idea, hoping naively (again) that it won't be as much work. Ideas are cheap, execution is hard. Good execution upfront is often too expensive until the idea has proved itself. Once you do have a solid sense of the value and potential success of the idea, it will have its own inertia. Our job is to game ourselves into getting that far along by making easy choices early. Yes, that is dangerous and will undoubtedly lead to tech debt and regrettable choices. But better a choice we regret because it is a victim of its own success than one we never have the opportunity to rue at all because we vacillated too long on its antecedent.

So, that brings us to the question of what tools to start with. This is in many ways much harder because we should account for our base level requirements while not hemming ourselves in as we expand to the fuller set. We should, but we wont. The metric of success, until there is a POC, is development progress. In the spirit of great writing, killing our babies should be expected. Everything we write now can be thrown away if we write it fast. The longer we take to get a POC, the more likely we won't make better tech selections in favor of workarounds from some sunken cost fallacy.

To that end, I'm going to choose roughly the first things I think of. Here are the immediate possibilities that spring to mind:

Frontend: 
Vanilla JS, because I have minimal UI requirements for a POC.   Don't need separate routes for survey form and dashboard. No login.
Framework. To get a headstart and some SSR frameworks play nicely with hosting providers like github pages, netlify, and vercel. For a framework, React is my strength, and I've never had cause to use Next.js. Nuxt.js is possible because I've been working in that most recently and it's still rather fresh. Finally, Svelte and sveltekit, because it's something I'd like exposure to. Haven't used it yet, but very curious. This is always a double edged sword. I have to recognize that I'm trading off learning-time for development-time.

Database:
Self-hosted (or something like EC2) MySQL or Postgres. Good = I want more experience with both. Bad, I have less experience. Could even use Postgres JSON for starters. Also, both can be run locally during initial development so I don't have to worry about infrastructure costs during a POC.
Firebase firestore?
DynamoDB is my first instinct. Lots of recent experience and moves the needle even closer to a fully CDK style app. (Not sure I want that lock-in, but it is quick development time). DynamoDB has a free tier I can explore. Calls to it early on can be done from local, so it's not self-hosted, but it may be similarly costed until I put a gateway or lambda in front of it.

API:
At the most basic level, the api will need to support CRUD operations on questions. The graphing can be done on the page. For a while (a short while) this can be very remedial. write new question responses and addenda into the keyed array for that question entity on the user entity. Reading can be simply getting all the user data back and doing on page calculations for what to display.
To that end, DynamoDB would also prove rather straightforward to start. Can use dynamodb local?