🌎 Set up common API types

Purpose

Closes #42

We want a canonical representation of our API that both the frontend and backend can use. It's quite easy to write down a schema for our API. It's a bit harder get the frontend/backend to use it. The scope of this PR will be limited to switching our backend over to something that uses those types.

Currently, we have the custom Router built, but our backend doesn't use it yet. One of the reasons it's not set up is because I'm too lazy to actually write the schemas for our APIs

Approach

Idea was inspired by Gary Bernhardt, but @jeffzh4ng and I couldn't figure out his implementation for the life of us. Instead we substituted a system of our own design. Maybe ours is better? We'll see about that when things are fully in place.

Alternatives? Here's one: https://hackernoon.com/express-fp-an-express-wrapper-for-type-safe-request-handlers-f8c411cc4a7b

I might've jumped on making my own solution just for the sake of flexing and putting it on a resume

We use io-ts instead of Joi, which will eventually enable clean and easy (de)serialization. This seems to be a staple of anyone who tries to make shared types a thing.

Testing

TODO

Open Questions and Pre-Merge TODOs

[ ] Use github checklists. When solved, check the box and explain the answer.

Learning

Describe the research stage

Lots of extremely arcane Typescript went into this. The official Typescript docs were the main source of information there.

Links to blog posts, patterns, libraries or addons used to solve this problem

Blog Posts

How to Pull Request Github Repo with Learning focused Pull Request Template.

loolabs / waterpark