Add OpenAPIFetchRuntime for Web APIs via JS interop

[MaxDesiatov]

Motivation

Swift for Wasm applications running in the browser are optimized for binary size and can't add dependencies like URL, Data, and so on, currently unavailable in Embedded Swift. Besides, the client transport that utilizes Web APIs like fetch can rely on available currency types directly bridged by JavaScriptKit via BridgeJS. This requires a separate runtime module hidden behind a corresponding trait.

Modifications

Added separate OpenAPIFetchRuntime module hidden behind JavaScriptFetch trait. This new module relies on Web APIs made available via BridgeJS and is compatible with Embedded Swift.

Result

Users of Embedded Swift for Wasm have an OpenAPI runtime available, hidden behind a trait.

Test Plan

N/A until Swift Testing is available for Embedded Swift.

[simonjbeaumont]

@MaxDesiatov I notice this is a draft, but presume you wanted to kick off some discussion.

I'm wondering if this represents the best layering. Some initial thoughts.

FWICT from your motivation, we need to have a different runtime abstraction that is free of the types that are not available on the target platforms, e.g. you called out Data and URL. Offering a more flexible, lower-level abstraction seems like a good idea, but the draft PR currently closely couples with JS, with the replacement ClientTransport.send protocol requirement taking a JSObject. Is there something less coupled we could use that would unlock adoption for these more constrained environments. Would something span-based suit?

Right now this package provides the abstraction and client transport implementations are provided in their own packages, e.g. swift-openapi-urlsession, swift-openapi-async-http-client. Now I realise that we set this up in a world without traits so we had no choice. However we liked this distinction because it kept this package lean and didn't create a first-party, third-party divide--we didn't want the barrier to entry be that transports need to be merged into this package. Also IIUC SwiftPM still only has experimental support for trait-based dependency resolution, so adding the JavaScriptKit would have a noticeable side effect for adopters, even when the trait is not enabled.

I saw you raised the platform versions in the package manifest. Is that necessary? It will be a breaking change in the package.

[FranzBusch]

I discussed this a bit with @MaxDesiatov. Right now there is no good way for us to layer a fetch based runtime into the existing OpenAPI runtime nor the new HTTP client/server APIs due to URL and HTTP types not supporting embedded Swift. It will take us some time to work through these issues and I suggested for Max to open a draft PR here with what he currently has. This already allows developers to use Max's branches to get something working while we can address some of the issues in the other packages.

[simonjbeaumont]

Thanks for the additional context @FranzBusch. If this is just being parked here as a WIP/PoC then that's fine, of course :)