Connect generated http server to the existing backend

[StefanSchade]

Goal is to connect the generated http server to the existing backend with the following boudary conditions

• Changes to the generated code (while necessary) should be kept at a minimum to facilitate further changes to the api associated with re-generation (these changes should be automated later on)

steps

• [ ] Refactor AppState to be part of the Entry-Point
• [ ] Change EntryPoint/main.rs to instantiate the generated server instead of the existing web adater
• [ ] Get the new web server running within the existing app and the dummy endpoints
• [ ] Inject the AppState into the new server
• [ ] connect the DomainStory business logic to the web handler
• [ ] test with curl or postman
• [ ] make it possible to switch between both webservers (find out wether we want to use conditional compilation and / or configuration to do so)

[StefanSchade]

i start with refactoring app state. my ide points out the following issues

Module adapter::web::controllers::player_controller uses module adapter::web::app_state which will be inaccessible after move Module adapter::web::server uses module adapter::web::app_state which will be inaccessible after move

configure_routes uses app state player controller uses app state.

So I can't move it without creating circular dependencies.

my intuition would be the following

• keep app state strictly on the adapter side
• use the Service_container (defined in service_container.rs) for the communication between adapter and entry_point (e.g. iin the message signature for start_server)
• for that we have to define an interface in the port layer (where our interfaces belong) all the repos, domain stories etc. are known in the port layer anyway - so we can define appropriate getters there

what do you think

[StefanSchade]

Your approach to handling the AppState issue seems thoughtful and strategically aligned with the modular architecture of your system. Here’s a breakdown of your plan and some further suggestions to refine and support the implementation:

Keeping AppState in the Adapter Layer

This decision helps in maintaining the separation of concerns and avoids bloating the entry point with direct dependencies on the web layer components. Keeping AppState within the adapter maintains encapsulation and focuses on its role in managing state for web interactions.

Using ServiceContainer for Communication

Expanding the role of ServiceContainer to act as the intermediary between the adapter and the entry point is a sound strategy. This avoids direct dependency on AppState from outside the adapter and leverages the ServiceContainer to manage dependencies.

Defining an Interface in the Port Layer

Creating an interface in the port layer for accessing repositories, domain stories, and other services is an excellent use of interface segregation principles. This approach allows you to expose only the necessary components to the entry point or other modules, reducing the risk of unwanted dependencies.

Here are additional considerations and enhancements to support your plan:

Expand ServiceContainer Capabilities

Interface Methods: Ensure that the ServiceContainer provides comprehensive access methods for all necessary components. Each component (e.g., repositories, domain stories) should be accessible via getter methods defined in the interface. Lifecycle Management: Consider how ServiceContainer will manage the lifecycle of the components it provides. Ensure that any stateful components are appropriately instantiated, shared, or disposed.

Interface Definition in the Port Layer

Clear Contracts: Define clear and concise contracts for each service or repository exposed through the port layer interface. This ensures that any module using these interfaces will have a predictable interaction. Documentation: Document each interface method thoroughly, explaining what each method returns, its side effects (if any), and its role in the overall architecture.

Refactor and Test Changes

Refactoring: As you move AppState and refine the ServiceContainer, refactor incrementally and run tests to ensure that each change does not break existing functionality. Integration Testing: After refactoring, perform comprehensive integration testing to ensure that the new interfaces and service container integrations work seamlessly across modules.

Handling Circular Dependencies

Module Reorganization: If certain modules become too interdependent, consider reorganizing responsibilities. For example, if a utility function or class causes dependency issues, it might be better placed in a more neutral module. Dependency Inversion: Use the Dependency Inversion Principle (DIP) to further decouple modules. High-level modules should not depend on low-level modules; both should depend on abstractions (e.g., interfaces defined in the port layer).

Update Documentation

Architecture Changes: Update your architectural diagrams and documentation to reflect the new structure and relationships introduced by these changes. Developer Guides: Provide guidelines and examples for using the new ServiceContainer and interfaces. This helps in maintaining consistency in future developments. This approach should ensure that your system remains modular, maintainable, and scalable while integrating the generated server and handling the complex dependencies of your backend architecture effectively.