The current AdapterCapabilities type is declared statically by each adapter at construction time. For the API adapter this won’t work — its capabilities depend on what the server reports via the /.well-known/stack discovery endpoint, which is only known after a network call.
Changes needed
The API adapter’s open() factory should call the discovery endpoint and populate capabilities before returning, so by the time Stack.create() is called they are already available synchronously. This keeps the StackAdapter interface unchanged — capabilities stays a synchronous readonly property — but the API adapter populates it during its async open() call rather than hardcoding it.
Notes
- The SQLite and JSON adapters can continue to declare capabilities statically — no changes needed for them.
- No changes to
packages/core are strictly required. This issue exists to document the pattern the API adapter must follow when it is built.
- Addresses the pattern before
@haverstack/adapter-api is written to avoid a design mistake.
The current
AdapterCapabilitiestype is declared statically by each adapter at construction time. For the API adapter this won’t work — its capabilities depend on what the server reports via the/.well-known/stackdiscovery endpoint, which is only known after a network call.Changes needed
The API adapter’s
open()factory should call the discovery endpoint and populate capabilities before returning, so by the timeStack.create()is called they are already available synchronously. This keeps theStackAdapterinterface unchanged —capabilitiesstays a synchronous readonly property — but the API adapter populates it during its asyncopen()call rather than hardcoding it.Notes
packages/coreare strictly required. This issue exists to document the pattern the API adapter must follow when it is built.@haverstack/adapter-apiis written to avoid a design mistake.