msgpack-javascript VS zod-to-openapi

For a compact message format being sent to browsers, you might look at messagepack, eg with https://github.com/msgpack/msgpack-javascript – it's essentially binary JSON, so it'd be compatible with OpenAPI specs.

I think the ser/des is slower than JSON in most browsers, but the message format is smaller.

Oftentimes, using a query parameter like `?exclude[]=…` or `?include[]=…` or similar to say "only get me these response fields, not the whole object" can be useful for this too (and then you still get JSON back).

This lib seems to be well managed, with frequent changes pushed. If it is made as per the spec, it should be compliant to work with your server too. https://github.com/msgpack/msgpack-javascript

Really cool, how does it compare to something like messagepack https://github.com/msgpack/msgpack-javascript ?

And if you like Zod, you might as well use this: https://github.com/asteasolutions/zod-to-openapi

It converts Zod types to OpenAPI specification.

Strong disagree.

The barrier you presume is that OpenAPI specs are hard to write. Raw oAPI in yaml is indeed a pain, but there are good DSL's out there.

I personally love Zod->OpenAPI, via https://ts-rest.com which uses https://www.npmjs.com/package/@anatine/zod-openapi. https://github.com/asteasolutions/zod-to-openapi is another alternative for Zod.

> The big bonus of the human documentation approaches today is that time is somewhat combined with building the client.

This is wild to me; human documentation is absurdly error-prone and it's almost always and immediately out of date. (Zod or other DSL) -> OpenAPI -> generated docs (and types! and clients! and mocks!) are always going to be better; always accurate, and faster. The upfront cost is slightly higher, but the ROI is _significant_.

OpenAPI specs lend themselves to excellent docs, ala Mintify or Docusaurus. Even interactive ones, like Swagger UI. The vast majority of API browsers & tooling understands OAPI, so why re-create (an often incomplete) version of the truth when using those tools?

> Whatever is overall fastest and gets me on to the problems I'm really trying to solve.

You may start (slightly) faster, but you'll incur significant cost when you move past the "trivial implementation" stage.

For instance: