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

21–30 of 76 posts

Re: Show HN: REST Alternative to GraphQL and tRPC

#21

Post by djha-skin »

> While REST APIs don'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.

REST is more secure, cacheable, and more performant on the server side as field resolution doesn't need to happen like it does with GraphQL. I'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'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't put cycles in your graphs.

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.

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.

1: https://connexion.readthedocs.io/en/latest/

Re: Show HN: REST Alternative to GraphQL and tRPC

#22

Post by throwaway11004 »

progx wrote: post #19
arcbyte wrote: post #17

There's no winning at this layer and every attempt is as doomed as medieval alchemists trying to transmute lead to gold. The key here is overall speed, but you can't trade the time spent learning/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 appl…

That is why we now step back to SSR-apps. No api necessary, no extra layers, no extra bloat and it is fast and scalable enough for the most apps.

Who's we?

Most apps nowadays have a mobile app, so you need the API anyways...

Re: Show HN: REST Alternative to GraphQL and tRPC

#23

Post by chrisweekly »

nine_k wrote: post #6
mortallywounded wrote: post #4

Is 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…

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.

Re: Show HN: REST Alternative to GraphQL and tRPC

#24

Post by CharlieDigital »

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.

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 frontend client generation and it's a fantastic DX with minimal wiring: https://chrlschn.dev/blog/2023/10/end-to-end-type-safety-wit...

Re: Show HN: REST Alternative to GraphQL and tRPC

#25

Post by coding123 »

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 standard at some point. We'll never get this shit right.

Re: Show HN: REST Alternative to GraphQL and tRPC

#26

Post by brodouevencode »

stetrain wrote: post #18
brodouevencode wrote: post #16

I want this, but language agnostic. 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'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. I'm not asking for implementations for every possible language given a framework. I'm asking…

There are libraries out there for a lot of languages that can generate OpenAPI specs for your APIs and generate clients from OpenAPI specs. This seems like a nice set of tools for doing so in Node/Typescript but the general pattern of using OpenAPI contracts is language agnostic.

The difference being that each language-specific framework has their own way of implementing the specs with the problem that some are done well and some are done half-assed. But then again, this problem exists with many specifications (OpenAPI is not alone). I look at it like this: the spec should inform the framework which should inform the (language specific) implementation. If the language specific implementation is it's own framework then so be it, but counter to the intentions of the layer above it. So why do all this? Enterprises have many teams that have many capabilities. How one (Python) team implements OpenAPI is drastically different than how another (Typescript) team implements OpenAPI, which causes a lot of friction when moving engineers around to different teams. If a spec desires to have mass adoption then providing at least heuristics for implementation will only increase that adoption.

Re: Show HN: REST Alternative to GraphQL and tRPC

#27

Post by dontlaugh »

CharlieDigital wrote: post #24
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.

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…

There’s also Twirp, if gRPC doesn’t fit your requirements.

Re: Show HN: REST Alternative to GraphQL and tRPC

#28

Post by datadeft »

djha-skin wrote: post #21

> While REST APIs don'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. REST is more secure, cacheable, and more performant on the server side as field resolution doesn't need to happen like it does with GraphQL. I'm told it is easier to develop against on the client s…

I concur. I usually implement a specific rest resource for use cases which is usually easier to do than implement a GraphQL backend.

Re: Show HN: REST Alternative to GraphQL and tRPC

#30

Post by anttiviljami »

isuckatcoding wrote: post #29

More a comment on the main page. 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.

Thanks for the feedback!

There is a full interactive sandbox example on the front/landing page https://openapistack.co

But point taken, will make sure code examples are visible on the overview page

Post reply on HN