Feature/Refactoring Proposal: Streamlining SDL Processing

[ygrishajev]

Current Challenges

Our SDL (Stack Definition Language) processing architecture presents several inefficiencies:

1. Scattered Responsibilities: Manifest processing is inconsistently distributed across the Cloudmos apps and the Akasjs library.
2. Overloaded Classes: The SDL class handles both validation and the generation of node and provider manifests, leading to convoluted logic.
3. Partial Dependencies: The Cloudmos application is also partially responsible for manifest generation, which complicates the integration process.
4. Layer Confusion: There's a lack of clear demarcation between the SDL/manifest generation processes and the GRPC layers.

Resulting Issues

These structural problems lead to:

1. Complex Client Code: Clients struggle with creating proper manifests due to unclear process delineation.
2. Reduced Maintainability: The architecture is difficult to debug, and tracking issues is cumbersome.
3. Documentation Challenges: The current implementation is complex and hard to document accurately.
4. Reliability Concerns: Modifications in one component can inadvertently affect others, leading to fragile system integrity.
5. Compromised Testability: Testing is hindered by intertwined dependencies and obscured logic.

Proposal Overview

This proposal seeks to rectify the aforementioned issues by restructuring the Sdl processing architecture to ensure modularity and robustness. Key components of the proposed architecture include:

Core Components

• Sdl Interface: Processes YAML strings, validates them, and provides a strict accessor method interface.
• ProviderManifest and BlockchainManifest: These classes accept an Sdl object as a dependency and expose methods to extract payloads specific to either providers or blockchains.
• SdlComposer: Orchestrates different versions of Sdl interfaces and manages their interactions.
• GRPC Layer: Interfaces with the SdlComposer to facilitate communication with nodes and providers.

Architectural Diagram

Attached is a detailed diagram illustrating the proposed system architecture, emphasizing the interaction between the core components.

Benefits

Implementing this proposal offers multiple advantages:

1. Enhanced Modularity: By adhering strictly to interface dependencies, the system's robustness is improved, mitigating the risk of cross-component impact.
2. Clear Separation of Concerns: This simplifies maintenance and boosts testability by delineating clear responsibilities.
3. Improved Documentation and Usability: A logical, well-defined structure is easier for clients to understand and for developers to document.

Implementation Guidelines

To ensure the effectiveness of the proposed changes:

1. Interface Implementation: All concrete classes should implement the defined interfaces, promoting consistency and flexibility.
2. Dependency Management: Dependencies should be based solely on interfaces to avoid tight coupling and enhance modularity.
3. Access Restrictions: Methods should be private unless public access is justified, to minimize maintenance overhead and potential for unintended usage.
4. Validation: YAML parsing and validation should be conducted using JSON Schema to confirm type accuracy, complementing other validation layers.
5. Protobuf Integration: Except for initial Sdl input parsing, all backend implementations should utilize protobuf-generated types to ensure consistency and reliability.

Conclusion

This proposal aims to streamline SDL processing by introducing a more structured, interface-driven architecture that enhances clarity, reliability, and maintainability. With clearer boundaries and a modular design, we can achieve a more robust and understandable system.