search

evomimic / map-proto1

Initial Proof-of-Concept of MAP Layer 0
Other
3 stars 0 forks source link

Encapsulate holochain tech dependencies? #13

Closed evomimic closed 2 years ago

evomimic commented 2 years ago

Should we try to isolate dependencies in our code on specific technology choices to make it easier to change those choices later?

evomimic commented 2 years ago

Failure to encapsulate technology choices can lead to proliferation of unwanted dependencies at all levels of the architecture, making swapping out the technology choice expensive. This might seem an odd thing to worry about for a prototype. Expending a lot of energy on tech encapsulation can lead to unnecessary complexity and over-engineering of code that may end up just being discarded.

However, in this particular prototype, one of the things we are playing with and hoping to learn about relates directly to code structuring and approaches to separation of concerns that can provide an evolvable structure to the MAP going forward.

evomimic commented 2 years ago

Holochain technology impacts two very different aspects of the MAP architecture:

  1. Holochain as persistence technology (storing app data in holochain DHT's)
  2. Holochain Conductor as execution container (analogous to a app server in a more conventional web application architecture).

The code structure (folder hierarchy, packaging) should align to the application architecture. Most holochain repos push coordinator and integrity zome distinctions very high in the repo structure.

Should we following more conventional naming (e.g., mid-tier, controllers, model, etc.) or follow the holochain distinctions of zomes (coordinator and integrity)?

evomimic commented 2 years ago

DECISIONS:

**_1. Isolate client/mid-tier code from dependencies on holochain in persistence layer.

  1. Follow holochain naming conventions (i.e., coordinator & integrity) and code structure_**

RATIONALE: For decision (1), some types of data may benefit from a different persistence technology (even if we retain holochain Conductor as overall execution environment). So its worth isolating, even if the likelihood of dropping holochain as a primary technology for the MAP is quite low.

For decision (2), aligning with standard holochain practice makes it easier for others to understand and provide feedback on our code and allows us to leverage available tooling (e.g., hc_scaffold tool). This feels more important than reducing the difficulty of switching out holochain Conductor as container.