Show HN: REST Alternative to GraphQL and tRPC

GraphQL is well over a decade old. I'm not sure "tried and tested" is a meaningful contrast between the two approaches at this point, especially as it relates to API requests from the frontend. It's okay for people to choose REST just because they like it better, and/or aren't interested in learning something different.

What I really like with graphql that IMO all the other spec lack is a nice human readable format. When as a team you design a new API no way I am going to write openapi spec, but I can reason in GraphQL schema. Then each side takes the contract and go implement the frontend and the backend and it just works.

Cool to see more of these kinds of projects, nice work OP!<p>I&#x27;m a huge fan of this general concept, so you&#x27;re definitely on the right path imo. That said, two things are jumping out at me:<p>- Users would still be writing OpenAPI specs&#x2F;JSON Schema by hand, an incredibly annoying and tedious process (unless using a nicer DSL)<p>- Generation&#x2F;build steps are annoying (but likely unavoidable here)<p>As pointed out by many other comments, an unfortunate amount of teams aren&#x27;t writing OAPI specs. I personally feel this is a major mistake for anyone building an API, but that&#x27;s a discussion for another day.<p>I&#x27;ve been using <a href="https:&#x2F;&#x2F;www.ts-rest.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.ts-rest.com</a>, a similar project, for a few months now. Instead of relying on OpenAPI specs as the source, you define the &quot;contracts&quot; using Zod. These contracts are essentially OpenAPI specs, but Zod makes for a MUCH better DSL. I really like that...<p>- Real-time type checking without generator steps, both server &amp; client-side. XHR clients like `fetch`, `react-query`, etc clients are inferred from the contract.<p>- The Zod contracts _can_ generate&#x2F;output OpenAPI specs and Mock Service Worker mocks for testing (as needed, not required)<p>- (Optional) Automatic request &amp; response validation based on Zod contract definitions, no additional code needed.<p>- (Node) Backend agnostic (partially, anyway: NextJS, Express, Nest and Fastify supported atm)<p>- Works very well with `react-hook-form` &amp; `ZodResolver`, so e.g an invalid value on client-side shows the same error as the API would have if request were fired.<p>- Zod types can be used as typescript (z.infer), a wonderful way to re-use e.g model types in client-side components.<p>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.<p>I am almost ashamed to look back on the many, many projects I&#x27;ve worked on where APIs and client-side did not share truth. Duplication of (hand-rolled) types, error messages, etc is horrific in retrospect.<p>I don&#x27;t want to think about the amount of bugs I&#x27;ve come across due to this dual (at best) truth approach.

After looking at tRPC, and having done a lot in a few jobs with GraphQL codegen &amp; gRPC codegen, I always wondered why there were so few recent OpenAPI based codegen&#x2F;client-server-contract tools. I think I was searching for this exact tool.<p>Love that it makes the client somewhat backend agnostic, but the tools for the OpenAPI backend also look great.<p>Thank you for this, I hope it is successful in achieving some adoption!

I want this, but language agnostic.<p>Let me explain: standards are great, type safety is great, API contracts are great. Locked into a particular language is not great. In fact it&#x27;s bad for the author. tRPC and now this assume my team has the desire and time to move to another language. The best frameworks assume none of that.<p>I&#x27;m not asking for implementations for every possible language given a framework. I&#x27;m asking for a framework for which any possible language can be built upon because the constructs are simple and easy to follow: graphql does this pretty well despite some of the nuances. Bonus points if the author provides examples out of the box in a variety of languages.

Congrats, this looks really nice! I recently finished a side project using Fastify and the Fastify Swagger plugin (which extends the built-in request and response validation and can dynamically generate an Open API definition) which was a good experience overall but the addition of request mocking and the solid documentation site shown here could tempt me to revisit it.

Awesome job! I really liked that you built it in a way that it&#x27;s framework-agnostic and you also have parameter validation built in!<p>This might be the best OpenAPI Typescript-based project I&#x27;ve seen so far. The ones I&#x27;ve used often tie you into a specific framework and do not perform any validation on the parameters at all.

Congrats on the launch!<p>How does this compare to other solutions, like <a href="https:&#x2F;&#x2F;openapi-ts.pages.dev&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;openapi-ts.pages.dev&#x2F;</a>?

Is it just me, or do these &quot;API contracts and type safety guarantees&quot; all call back to SOAP?

There&#x27;s no winning at this layer and every attempt is as doomed as medieval alchemists trying to transmute lead to gold.<p>The key here is overall speed, but you can&#x27;t trade the time spent learning&#x2F;understanding the API contract for these crazy complicated tools. The developer still has to look at the operations and data models exposed by the API, understand them, amd plan for how to integrate them into the larger application.<p>The big bonus of the human documentation approaches today is that time is somewhat combined with building the client. The downside of course is that it&#x27;s a human doing it. My point here is that you can&#x27;t take the time a human is going to spend understanding the API concepts and then tack on a bunch of time learning, configuring, and running the client gen code and associated infrastructure as well and expext that your solution is going to win.<p>The more complicated these codegen setups get, the less comicated just reading some docs and spinning up a few lines of client code is. And guess which I&#x27;m going to choose as a dev? Whatever is overall fastest and gets me on to the problems I&#x27;m really trying to solve.

GraphQL is more future proof than rest.<p>Rest is tied to HTTP forever - GraphQL can be separated, easily.<p>Rest communicates inputs and outputs in too many ways for my liking any more: headers, paths, bodies, query params, and dare I say method.<p>One complaint for GQL is that potentially they had a chance to standardize paging, filtering, etc... instead every schema is customized.<p>I guess we&#x27;ll have to create a new standard at some point. We&#x27;ll never get this shit right.

When I see API tools, I am bummed to see the diminished focused on API clients. Particularly client experience (not the libs).<p>Its all about REST vs GraphQL vs gRPC vs Async API vs native SDKs. It&#x27;s all about how to make it easier or faster for developers to build these APIs.<p>Never about, how to make this API best for the API client. That is what matters the most. Focus on clients and can they get the job done. If it does, no need to over engineer!

More a comment on the main page.<p>Show some code or small example on that main page. I have no idea or sense to compare it to graphql without some small toy example.

It’s a really good solution.<p>Wish it would use undicci&#x2F;fetch instead of axios though.

How do you make sure that the spec is in sync with the implementation?

GraphQL is RESTful. Just treat GraphQL Result as the resource..

&gt; While REST APIs don&#x27;t generally provide the same level of control to clients as GraphQL, many times this could be seen as a benefit especially in scenarios where strict control over data access and operations is crucial.<p>REST is more secure, cacheable, and more performant on the server side as field resolution doesn&#x27;t need to happen like it does with GraphQL. I&#x27;m told it is easier to develop against on the client side, and this is a trade-off, but I favor REST applications over GraphQL ones as a DevOps engineer. They are much easier to administer infrastructure-wise. I can cache the requests, I don&#x27;t need to stand up an Apollo router, and WAF support for GraphQL is still pretty nacent. My coworker found a GraphQL query only about five layers deep that could tip over a service. Please don&#x27;t put cycles in your graphs.<p>Data at our company suggests that several small requests actually do better performance-wise than one large one. We switched to GraphQL a year and a half ago or so, but this piece of data seems to suggest that we might have been better off (performance wise on the client side) just sticking with REST. My suggestion to that effect was not met with optimism either on the client or server side. Apparently there are server-side benefits as well, allowing for more modular development or something like that.<p>I have used OpenAPI using connexion[1]. It was hard to understand at first, but I really liked that the single source of truth was one schema. It also made it really easy to develop against the API because it came with a UI that showed the documentation for all the REST end points and even had test buttons.<p>1: <a href="https:&#x2F;&#x2F;connexion.readthedocs.io&#x2F;en&#x2F;latest&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;connexion.readthedocs.io&#x2F;en&#x2F;latest&#x2F;</a>

&gt; Many organizations choose REST over GraphQL due to more established conventions, simplicity, and the ability to leverage standard HTTP features directly.<p>I strongly disagree with this. REST APIs are usually a complete mess and follow no conventions at all. Even if OpenAPI is being used, the majority of OAS documents have errors or are entirely broken. I&#x27;m Working on tooling to automatically parse OAS and transform it to GraphQL schemas. There&#x27;s not a single day where we don&#x27;t find another broken OAS. Compare that to GraphQL where we now have powerful linters for schemas etc... But even without, the average GraphQL API is definitely in better shape than the average REST API, and that&#x27;s simply because the tooling enforces better boundaries. You might have a correct OAS vs every GraphQL server actually follows the GraphQL spec.

We&#x27;re pretty pleased with using trpc. With trpc-openapi, you can set up REST-like APIs. I like this method because it uses TypeScript and not YAML.