### Motivation

There are 12 resource implementations to write and maintain, that we know of so far. We want to minimize code duplicated amongst them as this will incur obvious maintenance burden, and it was already getting difficult to keep things consistent with just 2 implementations. The boilerplate code was getting quiet tedious when writing resource implementations, and it's likely that there will be more resource types to implement.

### Solution

I tried creating a higher order function that would take in another function that would be the resource creation function which the HOF would enhance. This turned out to be an inversion of what was required. Instead, the resource instance creation function (e.g. `defineFileResource`) calls a `getImplementers` function which takes a handful of arguments and returns a set of common properties and higher order functions that must wrap the CRUDD methods of a resource.

The downside of this approach is that anyone implementing a resource gets a little less guidance from the type system, but the upside is we don't have bidirectional data that they must flow between the higher order function and the concrete implementation, which gets very messy and confusing in a way outweighs the benefit of slightly better type hinting.

Co-authored-by: Anthony Manning-Franklin <anthony.manning.franklin@gmail.com>
Reviewed-on: #13

@@ -69,2 +69,4 @@
   });
 });
+Deno.test('derivePatchedConfig does not change unrelated values', () => {
+  // TODO: Doesn't account for changing application data