Skip to content

Commit

Permalink
Code Generation ADR (#3)
Browse files Browse the repository at this point in the history
  • Loading branch information
MatKuhr authored Aug 14, 2024
1 parent 95ca337 commit 07366c5
Showing 1 changed file with 81 additions and 0 deletions.
81 changes: 81 additions & 0 deletions docs/adrs/003-code-generation.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# Code Generation Strategy

Status: Draft, currently on hold. Requires further research into [existing OpenAPI tooling](https://openapi.tools/).

## Background

The capabilities of AI Core, including the orchestration service, and many foundation models are described using OpenAPI specifications.
With the code generators of the SAP Cloud SDK (adapted versions of the Open Source OpenAPI generators) we can generate client side Java and TS/JS code.

We can distinguish:

- APIs of foundation models
- Here we have virtually no control over the spec
- The specs sometimes contain objects not relevant for us
- The AI Core API
- Here we have some control over the spec, but can only apply compatible changes and the spec is partially generated itself
- The spec is particularly large
- The orchestration service API
- Here we have most control over the spec, it is designed to be extensible and will receive new features where we can influence the API spec

We can further distinguish generating DTOs (i.e. POJOs or model classes) and generating service (i.e. API) classes.

----

The main tradeoff between code generation vs. manually writing code is **quality** vs. **time**.

### Alternative 1: Use generated code as-is

Pro:
- Least effort
- High certainty that code conforms to spec, only generator bugs or feature gaps remain

Con:
- Most issues that cause the generator to fail need to be addressed in the spec
- API stability can not be guaranteed
- API quality varies from acceptable to unusable
- Everything is `public` API

### Alternative 2: Rely partially on generated code

Partially generate code, e.g. by allow-listing or block-listing individual class files in a pipeline script.

Pro:
- High flexibility
- API stability can be guaranteed

Neutral:
- Partial guarantee that code conforms to spec
- Manual work, effort & maintenance scales linearly with the % of manual vs. generated code

Con:
- Higher maintenance, requires diligent manual work
- Requires investment into tooling

### Alternative 3: Manually written code

Pro:
- Best API quality
- API stability can be guaranteed
- Full flexibility

Con:
- Highest maintenance, requires diligent manual work
- No correctness guarantee

## Decision (DRAFT!)

For the **AI Core API** we choose alternative **1**, generating everything.
- All API is considered beta and not guaranteed to be stable.
- We actively align on spec changes, ensuring the code generation and compilation succeeds, and improve API quality on a best effort basis.
- We test the aspects most relevant for GenAI use cases (Configurations, Deployments).

For the **foundation models** we choose alternative **2**, generating about 80-90 percent.
- We generate all DTO classes, potentially block-listing anything not relevant to us.
- We manually write the service class(es), as they contain rather little valuable generated code.
- We improve API quality on a best effort basis.
- We test most (75% or more) of the functionality

For the **orchestration service** we choose alternative **2**
- We generate all DTO classes
- We test most (85% or more) of the functionality

0 comments on commit 07366c5

Please sign in to comment.