Implement Recipe DNA

[pospi]

Recipe is probably the most complicated module left to implement, since it will include functionality that must integrate with the Planning DNA in order to publish production blueprints into actionable Planning records; as well as potentially being able to convert sets of Planning records into recipes so that blueprints can be easily created from previous work.

Must include the RecipeFlow, RecipeExchange, RecipeResource and RecipeProcess record types, and all associated indexes and functionality.

DEFAULT_VF_MODULES needs to be extended to have recipe added to the whitelist in order for queries & resolvers for this module to show up.

Ideally, #85 & #40 would be completed before starting so that there is a well-established and vetted pattern in use; otherwise it's just more stuff to refactor later.

[fosterlynn]

Just a note that we will probably be adding a few things to the recipe model based on work with the FabCity network. It's a great opportunity to hopefully create some interops between open hardware doc and VF recipes. I think what is in VF now will remain as-is, but we need to wait until they are far enough along that we can map to what they are doing, to be positive. Here's the thinking so far, based on a different but related open hardware effort: https://lab.allmende.io/valueflows/valueflows/-/issues/667#note_39196

[fosterlynn]

Just a note that we will probably be adding a few things to the recipe model based on work with the FabCity network.

Well, another note to say that FabCity didn't implement recipe (it was not prioritized), so we didn't get that experience.

As we get back to this for Carbon Farm Network, I'm reviewing RecipeResource to see if we really want/need that, I have doubts. RecipeProcess we do want.

[pospi]

If we decide to bypass protocol standardisation in VF-GraphQL, the pattern for adding this is reasonably straightforward.

If you search https://github.com/search?q=repo%3Ah-REA%2FhREA%20associateMyAgent&type=code that shows you all the places where you need to add code for a new hREA module's GraphQL bindings without dealing with VF-GraphQL. So we will need to declare a new set of these for the Recipe-related functions.

However the complication is that the spec already defines some Recipe types and queries (there are more edges in bridging/ too). So, we will be able to add fields to these and declare new types by extending from the base VF-GraphQL schema; but we won't be able to remove any fields or types that are already part of it without making upstream updates to the protocol.

[pospi]

With the latest protocol updates merged for Recipes and great work from @LeosPrograms on the core data structures we are close to being ready to merge on this.

The last detail is reverse query edges, which we might need help from @fosterlynn to resolve. Please adjust to correct the following, as the current situation with the spec appears ambiguous.

ProcessSpecification currently has two reverse query edges back to RecipeProcess:

type ProcessSpecification {
  conformingRecipeProcesses(first: Int, after: String, last: Int, before: String): RecipeProcessConnection
  recipeFlowsRequiringStage(first: Int, after: String, last: Int, before: String): RecipeFlowConnection
}

The latter appears to be erroneous, perhaps remaining from when RecipeResource was part of the spec? There appears to be no concept of stage related to the Recipe layer anymore.

• (suggestion): don't implement recipeFlowsRequiringStage and remove it from the GraphQL spec.
• ProcessSpecification.conformingRecipeProcesses should be updated when RecipeProcess records are created, updated or deleted.
  • The commented out code in handle_update_recipe_process, handle_delete_recipe_process and handle_create_recipe_process can be used as a guide in managing these fields.
  • hc_zome_rea_process_specification_index_specification will need to be updated to add the new indexes. They will be declared as remote; i.e. conforming_recipe_processes: Remote<recipe_process, process_conforms_to>.
  • You will also need to add remote_auth permission for index_process_specification_conforming_recipe_processes in bundles/dna_templates/specification that maps to the appropriate zome names. Simply follow the naming convention of the others and the index macros will match up.

There are currently no relationships defined for the reverse of RecipeFlow.resourceConformsTo. @fosterlynn let us know if there should be one, or if ProcessSpecification.conformingRecipeProcesses doesn't need to exist.

[fosterlynn]

ProcessSpecification currently has two reverse query edges back to RecipeProcess:

conformingRecipeProcesses should reference RecipeProcess
recipeFlowsRequiringStage should reference RecipeFlow (looks like it does actually)

Neither of those seem immediately needed, although I could be missing something. The first is more likely to be needed than the second. Note that the query naming defined in the spec is more like "if you need this query, this is what to call it", not "you need this query".

There appears to be no concept of stage related to the Recipe layer anymore.

RecipeFlow has a stage. We are using that in CFN, but not the inverse afaik.

ProcessSpecification.conformingRecipeProcesses should be updated when RecipeProcess records are created, updated or deleted.

In general, are you actually persisting the inverse query data? In a relational setting, I wouldn't do that, but of course I don't know how to think of it in holochain. If you are generally storing that data, let's review what we actually want, so not to impact performance needlessly.

There are currently no relationships defined for the reverse of RecipeFlow.resourceConformsTo.

Ah, I missed that when I took out RecipeResource, or maybe it was never in the spec, not all the recipe stuff was defined. So we could call that recipeFlows. Like ResourceSpecification.recipeFlows. It seems that one would likely be used in plan from recipe, although right now the plan from recipe is just happening in memory on the frontend in CFN. So maybe not, but in general there would be reasons for having that as an inverse relationship or query.