Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore [ADR] Code Generation #3

Merged
merged 1 commit into from
Aug 14, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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