openapi-backend
zod-to-openapi
openapi-backend | zod-to-openapi | |
---|---|---|
2 | 3 | |
579 | 690 | |
1.4% | 4.9% | |
7.7 | 8.3 | |
about 2 months ago | 29 days ago | |
TypeScript | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
openapi-backend
- Full stack typesafe API-first development for REST
-
Show HN: REST Alternative to GraphQL and tRPC
Cheers! Going from code first to schema first is definitely worth it in my experience! Especially when working in a team.
The nice thing is you already have an openapi spec, so it’s pretty trivial to eject from fastify swagger and switch to openapi-backend if you want!
Here’s an example of openapi-backend running on Fastify
https://github.com/openapistack/openapi-backend/tree/main/ex...
zod-to-openapi
- A library that generates OpenAPI (Swagger) docs from Zod schemas
-
Show HN: Build type-safe web APIs with JavaScript, instantly
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.
-
Show HN: REST Alternative to GraphQL and tRPC
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:
What are some alternatives?
openapi-client-axios - JavaScript client library for consuming OpenAPI-enabled APIs with axios
airform - Functional HTML forms for Front-End Developers.
msgpack-javascript - @msgpack/msgpack - MessagePack for JavaScript / msgpack.org[JavaScript/TypeScript/ECMA-262]
openapi-backend - Build, Validate, Route, Authenticate and Mock using OpenAPI
zod - TypeScript-first schema validation with static type inference
path-to-regexp - Turn a path string such as `/user/:name` into a regular expression
presupplied
connexion - Connexion is a modern Python web framework that makes spec-first and api-first development easy.
FastAPI - Easily create robust, standardized API endpoints using lightning-fast database queries
api - Instant API: Build type-safe web APIs with JavaScript