Show HN: REST Alternative to GraphQL and tRPC

Cool to see more of these kinds of projects, nice work OP!

I'm a huge fan of this general concept, so you're definitely on the right path imo. That said, two things are jumping out at me:

- Users would still be writing OpenAPI specs/JSON Schema by hand, an incredibly annoying and tedious process (unless using a nicer DSL)

- Generation/build steps are annoying (but likely unavoidable here)

As pointed out by many other comments, an unfortunate amount of teams aren't writing OAPI specs. I personally feel this is a major mistake for anyone building an API, but that's a discussion for another day.

I've been using https://www.ts-rest.com, a similar project, for a few months now. Instead of relying on OpenAPI specs as the source, you define the "contracts" using Zod. These contracts are essentially OpenAPI specs, but Zod makes for a MUCH better DSL. I really like that...

- Real-time type checking without generator steps, both server & client-side. XHR clients like `fetch`, `react-query`, etc clients are inferred from the contract.

- The Zod contracts _can_ generate/output OpenAPI specs and Mock Service Worker mocks for testing (as needed, not required)

- (Optional) Automatic request & response validation based on Zod contract definitions, no additional code needed.

- (Node) Backend agnostic (partially, anyway: NextJS, Express, Nest and Fastify supported atm)

- Works very well with `react-hook-form` & `ZodResolver`, so e.g an invalid value on client-side shows the same error as the API would have if request were fired.

- Zod types can be used as typescript (z.infer), a wonderful way to re-use e.g model types in client-side components.

This ts-rest experience has fundamentally solidified a belief in me: One single source of truth, propagating through the system, is _the_ best way to build safely and efficiently.

I am almost ashamed to look back on the many, many projects I've worked on where APIs and client-side did not share truth. Duplication of (hand-rolled) types, error messages, etc is horrific in retrospect.

I don't want to think about the amount of bugs I've come across due to this dual (at best) truth approach.

There are many, many frameworks for IPC/RPC or even REST that have human-readable schemas.

GraphQL is a performance nightmare, and while it might have nice and flashy dev tooling, it's fundamentally unoptimizable without extensive development investment - something that isn't an issue with REST.

Speaking personally as a full stack engineer, unless the backend is completely trivial to implement I find it much faster and more efficient to write and iterate JSON schema while implementing frontend features than actually implement backend logic first.

> My coworker found a GraphQL query only about five layers deep that could tip over a service.

I find arguments like this a bit odd. That's a pretty deep query in REST as well.

I don't have extensive experience with GraphQL, but the complaints I see about it often seem like things you just shouldn't be doing anyways - or, if you do, they're going to be rough in REST as well.

Grpc browser support is pretty bad, I still can't wrap my head around the whole grpc-web thing that looks like giant hacks.

Openapi is not human readable IMO and the point is you design the API waaaay before you write any line of code. The api should express the business needs and be a two way discussion with the frontend people.