APPDESCRIP-27 Spike - How to handle multiple implementations of the same interface

[DRAFT]

Spike Overview

ID: APPDESCRIP-27

Objective: Spike - How to handle multiple implementations of the same interface on EUREKA platform.

Background

The Application Formalization RFC aims to define an Application within the Folio project as the minimal but complete set of elements delivering a specific solution. This formalization intends to shift Folio away from monolithic releases toward modular components, improving setup, management, and deployment. The RFC outlines the structure, versioning, dependencies, and descriptors of applications, intending to streamline the development and maintenance of Folio while paving the way for an application marketplace.

Problem Statement

Stakeholders have raised concerns about the proposed dependency model in the RFC, highlighting potential issues with alternative implementations. Specifically, the current dependency system could lead to the need for multiple parallel application hierarchies if alternative implementations for interfaces (e.g., external configuration stores) are used. This complexity could result in significant maintenance challenges, as each hierarchy would need to be managed separately, leading to potential conflicts and inefficiencies. Addressing this issue is crucial to ensure the flexibility and scalability of the Folio application ecosystem.

Scope

This spike aims to investigate and propose solutions to address the dependency issues highlighted by stakeholders in the Application Formalization RFC. The primary focus is on ensuring flexible and manageable dependencies within the Folio application ecosystem, allowing for alternative implementations without causing maintenance complexities or requiring multiple parallel hierarchies of applications.

In Scope

• Analyzing the current dependency model outlined in the RFC.

• Identifying potential solutions for flexible dependency management.

• Proposing a refined dependency model that supports alternative implementations seamlessly.

Out of Scope

• Implementing the proposed solutions in the Folio codebase.

• Detailed design and development of new application descriptors.

• Changes to the existing Folio deployment processes.

Research Questions

N/A

Deliverables

Option 1 - Interface Abstraction and Loose Coupling:

1. Modify the application dependency management to allow for greater abstraction. Instead of requiring specific versions of an application, allow applications to depend on an interface or a set of interfaces. This would enable different implementations of the same interface to satisfy the dependency without needing to create multiple versions of the dependent applications.

2. Implement a dependency resolver that can understand and resolve interface-based dependencies based on the available implementations in the environment.

Pros

• Increases flexibility by allowing multiple implementations of the same interface.

• Reduces the need for parallel application hierarchies.

• Easier to swap out implementations without affecting dependent applications.

• Facilitates the scalability of the system by enabling easy integration of new modules or updates without extensive reconfiguration.

Cons

• Implementing a system that can effectively manage and resolve interface-based dependencies will be complex and require significant changes to the existing manager components and infrastructure.

• Introduces complexity in ensuring interface compatibility.

• Thorough testing is needed to ensure interface compatibility across different implementations.

• Makes it harder to predict exact behavior in complex setups.

Option 2 - Version Aliasing with Adapters:

• Introduce a mechanism for version aliasing where an alternative implementation can declare itself as a compatible version of another implementation. For example, app-external-configuration: 1.1.1 could declare itself as compatible with app-configuration: 1.1.1. Develop adapters that support such logic in the manager component.

Pros

• Allows for alternative implementations without modifying existing dependencies.

• Allows for backward compatibility with existing application descriptors.

• Simplifies the integration of new implementations.

Cons

• Could lead to confusion if not managed properly.

• Adds complexity to the system by introducing the need for adapters and aliasing mechanisms, which must be implemented in manager components and carefully managed to avoid introducing bugs.

• There is a risk of misconfiguration or errors in the aliasing definitions, which could lead to system failures or incorrect behavior.

• Might not be suitable for complex scenarios with multiple diverging implementations.

Option 3 - Dynamic Dependency Resolution:

• Implement a dynamic dependency resolution system in the application deployment process. This system could analyze the current environment and the available modules to dynamically link dependencies at runtime based on compatibility rules defined in the interfaces. So the application descriptors do not contain their dependencies statically declared, but the dependency resolution will be made dynamically during the entitlement process based on the modules' versions included in the applications.

Pros

• Maximizes flexibility in using different implementations.

• Reduces the need for static dependency declarations.

• Facilitates easier updates and replacements of modules since the system dynamically resolves dependencies based on current conditions.

Cons

• Late inconsistency detection (invalid dependencies will be detected at the entitlement phase, not the development phase).

• Increases complexity in the deployment process significantly.

• Introduces significant complexity in managing dependencies, as the system must be capable of making correct decisions dynamically.

• Requires robust runtime analysis and resolution mechanisms that must be implemented in the manager components.

• Unexpected behavior and side effects as the dependency resolution logic and state are more dynamic and potentially less predictable.

Option 4 - Semantic Versioning and Dependency Ranges:

• Encourage the use of broader dependency ranges and semantic versioning principles to reduce the need for exact version matches. This would allow applications to depend on any version of a module that meets certain compatibility criteria rather than a specific version. To solve the exact issue with a custom app-configuration, the institution/hoster can create and deploy their own version of the application app-configuration:1.1.1+custom.config.source instead of app-configuration:1.1.1 as long as it does not change the modules' interfaces declared in the original application.

Pros

• Leverages well-understood community practices around semantic versioning, potentially easing adoption and understanding.

• No need for additional complex mechanisms like resolvers or adapters.

• Easy to implement as it builds on existing versioning practices. No source code changes are needed in manager components.

Cons

• May lead to compatibility issues if broader ranges are not managed carefully.

• Requires strict adherence to semantic versioning principles by all module and application maintainers.

• May not be sufficient for cases where implementations diverge significantly.

• The creation of a lot of custom application versions could contribute to dependency hell scenarios.

Risks & Assumptions

Risks

• Complexity: Each proposed solution introduces varying degrees of technical complexity, potentially requiring significant development effort and thorough testing.

• Adoption and Compliance: There is a risk that not all developers and stakeholders will fully adopt or comply with new practices, such as strict semantic versioning or interface-based dependency management. Inconsistent adoption could lead to compatibility issues and undermine the effectiveness of the solutions.

• Unforeseen Edge Cases: Given the complexity of the FOLIO ecosystem, there may be edge cases or specific scenarios that the chosen solution doesn't adequately address.

• Increased Testing Requirements: More flexible dependency management will likely require more extensive testing to ensure all possible combinations work correctly.

Assumptions

N/A

Conclusion

TODO:

Spike Status: Completed IN Progress On hold

Attachments

N/A