Meta: Inter-Course-Phase communication concept

[Mtze]

Exchanging data between phases is currently limited to data stored within the cores database (course participation-metadata). This is fine for "small" data chunks related to students. In #126 we updated this model to distinguish between student accessable data and restricted data. For "simple" course phases (client only) phases this is sufficient. However, complex phases with their own microservice (maybe even their own access control mechanisms) this solution is not enough.

We envision a way that course phase implementations can directly exchange data - without an intermediate store in the core.

The course phase configuration interface already allows to see "required" and "provided" data that needs to be provided by one of the previous phases and data that may be used by a following phase respectively.

With the extension that services may provide data in their own API we need an abstraction / SDK that:

1. Allows to specify which data is required
2. Allows to specify which data is provided
3. Handles dynamic data resolution
   • For data that the core can provide from its own database - the value is prefilled
   • For data that is stored in a different phase implementation, an callable API is provided
   • The SDK needs to call the respective APIs and return the required data transparently to the phase implementation
   • If data resolution fails - we need to handle that
4. Handles API authorization by forwarding the users token to the core

Sub Problems

For this to work we need a few things

• An API standard to specify (API Versioned)

  • what data a phase implementation requires
  • what data a phase implementation provides
  • which data is provided by the core already - "Is available"
  • which data needs to be resolved by the SDK - "needs resolving"

• Implementations

  • Go SDK
  • Typescript SDK

Future Expansion

• A core API that allows phases to register special keycloak roles that are required for the respective phase implementation