1. Description

• API client generation (done in the openApiGenerate task) is currently using the java-micronaut-client generator type (further called micronaut in this document)

• problem: clients are dependent on a specific micronaut version, which means that incrementing a service’s micronaut version will require a recompilation of the client => undesired high coupling

• alternately, other generators can be used: java and kotlin

2. Comparison Results

• I generated the client API for the template-service with all 3 generators (see file attachments of this document)

• main points:

  • micronaut is in BETA, java and kotlin are STABLE

  • instead of relying on micronaut HTTP client, both java and kotlin generators use okhttp3 and other low-level dependencies

  • the alternatives are not drop-in replacements for the micronaut generator - replacing an existing client with one generated with java/kotlin will require some changes, depending on how the client was used (for example, the micronaut client is injectable out of the box), but these changes look to be rather minor

  • the public interfaces look similar (might need additional digging, with more complex use-cases)

  • micronaut version has more security features - do we use/plan to use features like auth on these clients?

• details on security features support:

  • micronaut: BasicAuth, ApiKey, OpenIDConnect, OAuth2

  • kotlin: BasicAuth, ApiKey, BearerToken

  • java: NONE

  • handling date and datetime (taken from docs):

    • notice that micronaut and java are identical, so we can’t expect any improvements here if going with java over micronaut

    • kotlin is different, but is it better or worse? need to decide

3. Next Steps

• ask IAM - what auth should the API clients have, if any? are these clients called from FE app? → FE does not use these clients