Refactor disk persistence #20
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refactor-disk-persistence"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Motivation
A lot of the application logic was scattered across the translation layer, lifecycle services, and resource implementations. Now that the first use case has mostly been implemented, we need to consolidate the software architecture
Solution
We want to distinguish between primary types and input types. All types are assumed to be primary types, unless they have the input suffix. Input types must not be used outside of the translation layer, e.g. they must only be used in a route handler and must not be used in derivers.
To fulfill the above architecture directive, I created an adapter that transforms the
ServerConfigInputinto theServerConfigprimary type. But this approach had an issue in that it needed the data from the application manifest. I realized there's not a lot of point leaving the application manifests on disk and waiting until we need them before reading them into memory. So I created an app manifests lifecycle service that loads the manifests into memory and provide them to the rest of the application. This allowed us to synchronously retrieve the app manifest inside the adapter.I thought it was weird that the patch config controller had a lot of logic regarding how to perform a transaction to update and implement configuration changes. I moved these responsibilities into the config service, which means other controllers are going to be able to reuse this logic.
In the process of implementing the adapter, a lot of responsibility was extracted from the application resource, since it was mostly trying to figure out how to transform the input type into the resource definitions.