feat(smithy): add canonical Smithy models for APIs#51
Conversation
Adds Smithy IDL definitions for Supabase Storage and Edge Functions HTTP APIs as a shared source-of-truth for cross-SDK codegen spikes. Each SDK team runs their own generator toolchain against the same models. Includes: - model/common.smithy — shared shapes (StringList) - model/storage.smithy — buckets, objects, signed URLs, TUS resumable uploads - model/functions.smithy — invoke operations for GET/POST/PUT/PATCH/DELETE - smithy-build.json — Smithy CLI / Gradle build config - patch-openapi.py — post-generation patches for streaming blob and multipart - openapi/ — committed generated OpenAPI 3.0 artifacts (patched) Known limitations documented in README (streaming blob format, multipart, dynamic query params). Auth and PostgREST models are not yet included — each SDK spike (SDK-1103 through SDK-1109) must assess those layers. Related: RFC auto-generating parts of the Supabase SDKs Swift spike: supabase/supabase-swift#1047
Adds model/database.smithy covering the full PostgREST HTTP surface:
- SelectRows / InsertRows / UpdateRows / UpsertRows / DeleteRows on /{table}
- CallRpcPost / CallRpcGet on /rpc/{functionName}
- Fixed query params: select, order, limit, offset, on_conflict, columns
- Well-known headers: Prefer, Range, Range-Unit, Accept, Accept-Profile,
Content-Profile, Content-Range
- FilterOperator enum — all 24 PostgREST operators generated as typed constants
- @httpQueryParams filters: StringMap on read/write inputs so column=op.value
filter params are model-declared and generated (not hand-wired middleware)
- @httpQueryParams args: StringMap on CallRpcGet for function-specific params
Also adds StringMap to common.smithy and uses it in functions.smithy to express
FunctionInvokeOptions.query (previously listed as a known limitation).
Adds database-openapi projection to smithy-build.json.
Runs smithy build + patch-openapi.py to produce the committed artifact that SDK consumers can feed directly into their generator toolchain. patch-openapi.py gains a database-specific branch (detected by info.title) that injects the FilterOperator enum into components/schemas — the enum is declared in database.smithy but absent from Smithy-generated OpenAPI because it is not directly used as a member type (filter map values are raw strings).
…ranch The SDK branch (supabase/sdk#51) now includes a DatabaseService model. Generate a DatabaseApi from it to verify the emitter works against every model in the branch. Type query parameters by their schema instead of always String?, and add PostgREST transport coverage.
… uploads The @httpMultipartForm custom trait is stripped as a DynamicTrait by the Smithy OpenAPI converter before any OpenApiMapper.updateOperation hook runs, so the Java plugin approach cannot work without significant additional infrastructure. Restore the simpler approach: patch-openapi.py injects the multipart/form-data requestBody for UploadObject (POST) and UpdateObject (PUT) in the StorageService OpenAPI artifact. The @httpMultipartForm trait stays in the model as documentation. The MultipartFormOpenApiMapper Java plugin is kept for reference but marked inactive.
|
Two fixes needed:
Also, |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Adds Smithy IDL definitions for Supabase Storage, Edge Functions, and PostgREST (Database) as a canonical source-of-truth for cross-SDK codegen spikes. The goal is for every SDK team to run their own generator toolchain against the same shared models.
These models were developed during the Swift codegen spike (supabase/supabase-swift#1047) and are now promoted here so other SDK teams can use them as a starting point.
What's included
Key design decisions
FunctionInvokeOptions.method.FunctionInvokeOptions.queryis now expressed via@httpQueryParams query: StringMapon all function inputs./{table}plusCallRpcPost/CallRpcGeton/rpc/{functionName}. Key additions:FilterOperatorenum — all 24 PostgREST operators generated as typed constants in every SDK.@httpQueryParams filters: StringMapon read/write row inputs — each map entry serialises to a?column=op.valuequery param (e.g.{"id": "eq.5"}→?id=eq.5). The query-builder API (.eq(),.like(), etc.) that populates the map stays hand-written; that's a UX layer, not a transport gap.@httpQueryParams args: StringMaponCallRpcGetfor function-specific GET params.Blob— row shapes are table-dependent and cannot be statically typed.Known limitations
@streaming blobemitsformat: byte; generators needformat: binarypatch-openapi.pymultipart/form-datain Smithypatch-openapi.pyinjects upload operationsInvokeFunction*operationsGET+@httpPayloadis illegal in SmithyInvokeFunctionGetInputwithout a bodyreturn=representation— Smithy requires a single success codeNot yet modelled
Auth is out of scope for this PR but is required scope for each SDK spike. OAuth redirects and cookie-based session management are difficult to express in Smithy; teams may find that layer unsuitable for codegen.
Related
DO NOT MERGE
This is a living draft. It will be updated as Auth models are added and as each SDK spike surfaces gaps that require model changes.