Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: REST Alternative to GraphQL and tRPC

openapistack.co

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Show HN: REST Alternative to GraphQL and tRPC

#61

Post by mdaniel »

anttiviljami wrote: post #37
coding123 wrote: post #25

GraphQL is more future proof than rest. Rest is tied to HTTP forever - GraphQL can be separated, easily. Rest communicates inputs and outputs in too many ways for my liking any more: headers, paths, bodies, query params, and dare I say method. One complaint for GQL is that potentially they had a chance to standardize paging, filtering, etc... instead every schema is customized. I guess we'll have to create a new stan…

I don’t really agree GraphQL is somehow more ”future proof” because it doesn’t use as many HTTP features. It’s not like HTTP is going to go away in a while. I find that AsyncAPI is a nice extension of OpenAPI/REST ideas if you need to go beyond request / response.

If I'm understanding coding123's comment correctly, I think AsyncAPI would need to be extended to allow specifying a GraphQL schema and not just a JSON schema as the message payload and (I guess implied?) response types

Re: Show HN: REST Alternative to GraphQL and tRPC

#62

Post by gadflyinyoureye »

anttiviljami wrote: post #59
gadflyinyoureye wrote: post #58

Earlier quoted context omitted.

Auto generate the contract. That might be easier in some languages like TypeScript or Java, but it’s just done as part of the build.

You don’t actually want that. Code should not inform design. Design informs code.

Use the code to do the design. Don’t implement the damn thing. Just work in a nicer medium like Typescript. Add attributes. Remove attributes. Move things around in the refactoring tool. Then generate the doc. Forget about the whole “this is what the database does” stuff.

Re: Show HN: REST Alternative to GraphQL and tRPC

#63

Post by theogravity »

Awesome job! I really liked that you built it in a way that it's framework-agnostic and you also have parameter validation built in!

This might be the best OpenAPI Typescript-based project I've seen so far. The ones I've used often tie you into a specific framework and do not perform any validation on the parameters at all.

Re: Show HN: REST Alternative to GraphQL and tRPC

#64

Post by anttiviljami »

theogravity wrote: post #63

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

Thank you for the kind words!

Re: Show HN: REST Alternative to GraphQL and tRPC

#65

Post by CharlieDigital »

Sytten wrote: post #40
CharlieDigital wrote: post #24

Earlier quoted context omitted.

If you want to do that, try gRPC and Proto. But I feel like REST and OpenAPI are fine especially if you start from the backend. I think with .NET Web APIs, the story is particularly good since it has out-of-the-box tooling for OpenAPI spec generation based on your exposed endpoints and models and then the option to customize that as needed. I've recently been working with it trying to get hot reload working on the fr…

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.

OpenAPI itself doesn't need to be human readable because it's readily translated into human readable form using tools like Redocly, RapiDoc, or any other host of tools that create output documents from input OpenAPI spec.

Re: Show HN: REST Alternative to GraphQL and tRPC

#66

Post by paulddraper »

andrewingram wrote: post #57
paulddraper wrote: post #53

Earlier quoted context omitted.

GraphQL's first draft release was 8 years ago. [1] It's first non-draft release was 5 years ago. [2] It's first release under community governance was 2 years ago. [3] [1] https://github.com/graphql/graphql-spec/releases/tag/July201... [2] https://github.com/graphql/graphql-spec/releases/tag/June201... [3] https://github.com/graphql/graphql-spec/releases/tag/October...

I think I shipped my first production GraphQL server around this time 8 years ago, but by all accounts it was in use at Facebook a couple of years before it was opened up. So overall ~10 years old sounds right, though the released spec is a little different to the internal version that predates it.

By that standard MyCorpInnerPlatform is very mature.

Re: Show HN: REST Alternative to GraphQL and tRPC

#68

Post by lbhdc »

junon wrote: post #34
Sytten wrote: post #8

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.

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.

> 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.

That feels really true. I worked on a really large gql api, and it was a performance nightmare, lots of 10+ second queries that thrashed our database.

Fine grained security was a nightmare. We found no existing solutions, and rolled a few different solutions for this that were all awful and leaky. Eventually we threw a bunch of money at h1 to tease it all out.

Re: Show HN: REST Alternative to GraphQL and tRPC

#70

Post by nine_k »

chrisweekly wrote: post #23
nine_k wrote: post #6

Earlier quoted context omitted.

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…

Speaking from painful experience, gRPC is an absolutely terrible choice for client-server interactions. Google (its creator) discourages its use except for server-to-server, and Improbable labs' grpc-web library is handcuffed to brittle and rapidly-aging web tooling.

GRPC is compact; in some cases it's important.

What would you suggest, beyond the standard "ReST" and GraphQL, with OpenAPI as a declarative description?

Post reply on HN