Desgin the initial expected Json input

[nemerna]

as we still do not have an idea how our FE will be sending the diagram exactly to the BE we know it will be a JSON code, representing the diagram as the main object and other shapes as child objects for the Diagram.

each Child Object will be representing a "Shape/Mockup", where each shape will have its own visualizing properties and other properties related to its definition once converted to a k8s resource definition.

[nemerna]

suggesting the following Logic. as an architect, I need to focus on what I need to deploy and not on where or how. example: as an architect, I'm interested in deploying a Pod, and a Service and I am interested in linking the connection from the deployed service to the deployed pod

Archetict does not need to take care of the name of the deployed service/pod or in the image name used inside the pod, those should be handled by the teams willing to deploy whatever the Archetict has designed.

for that, we will be splitting the logic into 2 kinds of diagramming

1) a Diagram object which is the Diagram designed by an Archetict 2) a DiagramInstance which is an instance of the Diagram object Designed by the Archetict

the Diagram Instance is the same as a Diagram except that it will offer you on the FE, the ability to have a Dynamic Form corresponding to each Shape inside the Diagram, where Dynamically each form will urge you to fill each Required field for each K8s Object corresponding shape in the Diagram Instance

additionally, we may add some unique shapes that will act as a Parameter store that can be shared between multiple shapes (similar to the Values File in Helm)

will be following with more details in the following comments.

[nemerna]

as described in the previous comment, we will need to define the Diagram object as an input for the Translation Service.

a simple 1 pod 1 service linked with 1 arrow is supposed to be similar to the following definition [ { "Id": 1, "Name": "My Diagram" }, { "Id": 3, "Name": "basic-pod", "Shape Library": "Kubernetes", "Page ID": 2, "apiversion": "v1", "kind": "Pod" }, { "Id": 4, "Name": "basic-service", "Shape Library": "Kubernetes", "Page ID": 2, "apiversion": "v1", "kind": "Service" }, { "Id": 5, "Name": "Line", "Page ID": 2, "Line Source": 4, "Line Destination": 3, "Source Arrow": "None", "Destination Arrow": "Arrow" } ]

as you see each shape "the pod and the service" have the fields APIVersion & Kind which is somehow critical for us, so we can know once the user asks to create an instance out of the above diagram, the translation service (or other BE Component) will need to fetch the possible (required/optional) fields for that shape using the corresponding K8s Resource definition saved in particular K8s/OCP cluster.

maybe for the K8s BuiltIn resources, we will have a hardcoded forms, but for the future we will need this logic for supporting the CRDs Dynamically without the need / with low need for human interaction with the CRD itself for building the form