Show HN: REST Alternative to GraphQL and tRPC
openapistack.co
Show HN: REST Alternative to GraphQL and tRPC
1–10 of 76 posts
Re: Show HN: REST Alternative to GraphQL and tRPC
#2Congrats on the launch!
How does this compare to other solutions, like https://openapi-ts.pages.dev/?
Re: Show HN: REST Alternative to GraphQL and tRPC
#3Congrats on the launch! How does this compare to other solutions, like https://openapi-ts.pages.dev/ ?
Good idea to add to the comparisons page!
The openapi-typescript package is a library for generating types from openapi spec, similar to the openapicmd typegen command provided by openapi-stack.
The new openapi-typescript-fetch seems similar to openapi-client-axios, but using fetch instead of axios for a more lightweight approach.
Both libraries are great and well aligned with goals of openapi-stack!
In addition to type generation and consuming APIs, https://openapistack.co provides tools for building and mocking API backends with the openapi-backend library, as well as a general cli tool to work with openapi files and invoke APIs via the command line.
The core mission of https://openapistack.co is to bring together tools for an end to end full stack toolkit for building and consuming typesafe REST APIs.
Re: Show HN: REST Alternative to GraphQL and tRPC
#4Is it just me, or do these "API contracts and type safety guarantees" all call back to SOAP?
Re: Show HN: REST Alternative to GraphQL and tRPC
#5Is it just me, or do these "API contracts and type safety guarantees" all call back to SOAP?
WSDL
Re: Show HN: REST Alternative to GraphQL and tRPC
#6Is it just me, or do these "API contracts and type safety guarantees" all call back to SOAP?
The core idea of SOAP was good. The ability to generate client and server code stubs from a single declarative file was great. I worked with SOAP extensively in early 2000s.
The problem that killed SOAP, to my mind, was growing complexity that eventually started to outweigh the benefits of the protocol. Not every implementation supported every new complication that, say, MS kept inventing, it hurt interoperability.
I think a modern sort-of-replacement for the SOAP's use case is GRPC. It eschews the heavyweight XML and tries to keep things simple, while staying reasonably typesafe, declarative, discoverable, and extendable.
Re: Show HN: REST Alternative to GraphQL and tRPC
#7Is it just me, or do these "API contracts and type safety guarantees" all call back to SOAP?
Yes! SOAP wsdl, but json
Re: Show HN: REST Alternative to GraphQL and tRPC
#8What 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.
Re: Show HN: REST Alternative to GraphQL and tRPC
#9GraphQL 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.
Re: Show HN: REST Alternative to GraphQL and tRPC
#10We'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.