How should we structure the code to be a framework?

[fosterlynn]

We have said that holo-rea will be an REA framework that others can build on top of with application or domain specific logic. What does that actually mean in the context of holochain architecturally? And when do we want/need to figure this out? Is there a specific group we are working with where we could work through the question in practice?

Or if we do understand it, I'd be interested in hearing how it should work.

[pospi]

Good question! I have been slowly feeling this out... it is also true that words like "framework", "app", "backend" and so on are rapidly losing meaning in this weird new tech space. For me a lot of it is about fulfilling the intentions of the Open App Ecosystem. So, I'll do my best at a preliminary answer and we can expand from there...

The first (and possibly most obvious) use-case of an REA network is deploying every module together as a complete set, with a 1:1 relationship between modules. In this scenario, HoloREA would function much like NRP as one big system. Probably not much more explanation needed there.

The simplest level of customisation starts to approach what could be considered "frameworky"- deploying individual HoloREA modules to service specific bits of functionality. An example could be a business which wants to expose supply chain data using REA, but nothing else.

There is a path here for non-technical users to deploy complex and powerful backend services by using existing Holochain DNAs. Someone could piece together a system for resource coordination which is partially constructed from HoloREA modules, partially from others. As an example, they might use a different mapping DNA or a different module for coming to agreements instead of the ones we provide.

The same pattern could be used by technical teams wishing to compose domain-specific business functionality on top of HoloREA. They could have their business logic in one DNA and push REA data down into HoloREA for integrating with compatible neighbouring networks. A side effect of using our DNAs in unaltered form like this (aside from provable spec compliance) is that the REA components of their system can be upgraded independently of the rest of their software stack.

Then at one level deeper, developers could treat the HoloREA DNA code as "framework" in the truest sense and consume it as a Rust module within their own DNAs. This allows them to do the deepest levels of customisation but relies on them to maintain spec compliance and makes both implementing and managing updates to HoloREA more difficult.

So that's how it looks to me from within the codebase. But if we go sideways rather than downwards I think there are "frameworky" things that can be achieved simply with different network connection structures. One example is two separate private observation modules tracking supply chain events, being coordinated in a shared planning space. Another is multiple tiers of observation modules replicating data between each other- for example, resource tracking data from a farm being automatically broadcast to a regional distribution hub. In this context you could think of whole HoloREA modules as being a framework for building up complex resource sharing ecosystems.

Then there's the user interface, which sits alongside all of this— every DNA also comes with 1 or more UIs packaged into it. I imagine these will be much like Shroom in that they will be general-purpose interfaces with a lot of power behind them. But not every app wants that, so there will be cases where developers create their own separate interfaces which will sit on top of HoloREA DNAs but present 'friendlier' ways of interacting with it.

And in doing so, those developers might use the UI component library that we develop the general-purpose interfaces with in order to have consistent presentation between apps. So that too is a way that pieces of HoloREA can be used as a framework.

[pospi]

Anyway, in terms of "how should we structure the code"- we're already doing it; but some loose ends will inevitably need tying off when it comes time to publish (publishing zome modules to crates.io, publishing UI components to npmjs.org, publishing & code signing the DNAs etc).

I haven't really done much about the UI pieces yet, but it would be the same as Ivan & I did in rea-app. Basically using a monorepo to keep code in sync easily and ensuring that we develop our own apps as consumers of our modules, so that they have no unexpected dependencies when they are eventually published.

[fosterlynn]

For me a lot of it is about fulfilling the intentions of the Open App Ecosystem.

:+1: Me too.

Thanks for the thoughts, all interesting. A couple of those options would work for one scenario I was wondering about: what if a user group can basically use our REA DNA(s) but wants to add a few domain specific fields.

[pospi]

Yeah, and that use-case can be done in a couple of ways- they can wrap our DNA in a domain-specific DNA and proxy the underlying 'standard' record through; or they can fork our zome code and implement their own extensions there. I guess the appropriate path largely depends on whether their custom code requires its validation to be integrated with the VF validation rules in complex ways.

[pospi]

I think answers to this question are unfolding naturally as development progresses; rubber is hitting the road in #80.