Smithy → OpenAPI → Go codegen spike

Caution

The contents of this repository have been generated by Claude in order to quickly test and validate, based on questions asked and standards we wish to align with. For more details see Linear issue SDK-1108 (Supabase-internal).

Isolated playground for the Go codegen spike. It runs entirely here and touches no product repository. It exercises both Go generators named for the spike (oapi-codegen and ogen) against the three committed, already-patched OpenAPI documents from supabase/sdk#51 (Storage, Functions, Database), then reports build status, dependency footprint and idiomaticity signals.

This is a throwaway experiment to see what the generators emit. The generated code is not, and will not become, the SDK.

Prerequisites

• go on PATH (confirmed present as go1.26.4). Network access is needed for go install and go mod tidy.

Inputs (already staged)

• openapi/StorageService.openapi.json
• openapi/FunctionsService.openapi.json
• openapi/DatabaseService.openapi.json

These three files are a pinned snapshot of supabase/sdk at branch feat/smithy-models (PR #51), fetched on 2026-07-06 and committed here so the experiment reproduces even as that draft branch moves. They are the generated-and-patched OpenAPI the model authors publish for exactly this purpose, so no Smithy or JVM is needed. supabase/sdk is MIT-licensed, and this repository's LICENSE carries both copyright notices accordingly.

Run order

From this directory, all at once:

bash scripts/run-all.sh

or one step at a time:

bash scripts/00-preflight.sh          # go env, and install oapi-codegen + ogen
bash scripts/01-generate-oapi.sh      # generate all three services with oapi-codegen
bash scripts/02-generate-ogen.sh      # generate all three services with ogen
bash scripts/03-build-and-measure.sh  # build both, measure dependency footprint
bash scripts/04-inspect.sh            # grep probes for the ten SDK-1108 questions
bash scripts/05-real-footprint.sh     # modules actually linked (go list -deps), not the inflated module graph
bash scripts/06-ogen-minimal.sh       # ogen at its leanest: client-only, no OpenTelemetry, no webhooks

Results

Everything lands in results/. results/SUMMARY.txt assembles the headline numbers from every step, and per-step detail (generator logs, deps.txt, build logs) sits alongside it. The one dimension the scripts cannot measure is taste: read the generated code (start with oapi/gen/storage/ and ogen/gen/storage/) and judge whether you would be comfortable owning the internal layer each generator produces.

How it is laid out

• oapi/, ogen/ and ogen-min/ are separate Go modules, one per generator configuration, so each transitive dependency closure is measured cleanly. The headline question is whether the generated code drags in a runtime (OpenTelemetry, jx) that would ship to consumers and break the minimal-dependency standard.
• scripts/lib.sh holds shared setup and is sourced by every step.
• Re-running is safe: steps overwrite their own outputs.