[ljm]

You can generate TS from an OpenAPI spec and then create type-safe mocks of network calls.

Basic mocks and fake servers run the risk of falling out of sync and giving false positives, or just being outright wrong to short-cut some of the work. It's also less code to maintain when a service worker can intercept the call, instead of orchestrating a load of mock APIs.

It won't stop you making breaking changes on the API but it will keep you honest on consuming the API on the client.

[Klaster_1]

Too bad this only gets you so far. Last time I checked, the OpenAPI specs are not as flexible as TS types and the people who author these - probably the team members responsible for the backend - won't necessarily even be able to list all the invariants due to framework and host language constraints. And OpenAPI does not support WebSockets. The project I work on has a frontend written in TypeScript, a Java backend, an Express-based dev-server that shares same types with FE, but none of the solutions the team evaluated enables the type sharing across all three beyond simple "an object can have these fields" - no algebraic data types, no WebSocket support. In the end, we resorted to agreeing on as much as possible in plain text before greenlighting the new endpoint, and then double checking the implementation and client usage for unexpected behaviors.

[ljm]

For those use-cases you might just be better off with either contract tests or simply making the payload itself typesafe with something like protobuf.

OpenAPI/Swagger is basically inextricably bound to REST/JSON APIs over HTTP. I also think they're quite abstruse in terms of defining non-trivial interfaces.