Show HN: REST Alternative to GraphQL and tRPC • Hacker News Board

Re: Show HN: REST Alternative to GraphQL and tRPC

#71

Post by rattray » Tue, Oct 10, 2023, 9:51 PM UTC

nine_k wrote: post #70

chrisweekly wrote: post #23

Earlier quoted context omitted.

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?

For a compact message format being sent to browsers, you might look at messagepack, eg with https://github.com/msgpack/msgpack-javascript – it's essentially binary JSON, so it'd be compatible with OpenAPI specs.

I think the ser/des is slower than JSON in most browsers, but the message format is smaller.

Oftentimes, using a query parameter like `?exclude[]=…` or `?include[]=…` or similar to say "only get me these response fields, not the whole object" can be useful for this too (and then you still get JSON back).

Re: Show HN: REST Alternative to GraphQL and tRPC

#72

Post by jimiljojo » Tue, Oct 10, 2023, 11:46 PM UTC

When I see API tools, I am bummed to see the diminished focused on API clients. Particularly client experience (not the libs).

Its all about REST vs GraphQL vs gRPC vs Async API vs native SDKs. It's all about how to make it easier or faster for developers to build these APIs.

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!

Re: Show HN: REST Alternative to GraphQL and tRPC

#73

Post by 8note » Wed, Oct 11, 2023, 12:15 AM UTC

t1mmen wrote: post #32

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…

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

My big foot gun for this is that you can manually write jsonschema that doesn't have a nicely serializable java representation, making it hard to use cross-language, and you don't find out that that's the case until you try

Re: Show HN: REST Alternative to GraphQL and tRPC

#74

Post by mikercampbell » Wed, Oct 11, 2023, 12:33 AM UTC

jimiljojo wrote: post #72

When I see API tools, I am bummed to see the diminished focused on API clients. Particularly client experience (not the libs). Its all about REST vs GraphQL vs gRPC vs Async API vs native SDKs. It's all about how to make it easier or faster for developers to build these APIs. 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…

Did you ever play with Realm.io? It had a ton of promise, and I loved the idea of “OOP API”, where objects write themselves to the database from your app.

My opinion is more nuanced now, but still it’s super cool.

Re: Show HN: REST Alternative to GraphQL and tRPC

#75

Post by barefeg » Wed, Oct 11, 2023, 6:12 PM UTC

anttiviljami wrote: post #60

barefeg wrote: post #56

Earlier quoted context omitted.

Maybe I didn’t explain the process correctly, we do generate the spec first, it’s just that the tool we use for creating the spec is the code that will later contain the implementation.

Ah nice! Mind sharing what you’re using to generate the spec?

FastAPI which is a python framework

Re: Show HN: REST Alternative to GraphQL and tRPC

#76

Post by nlarew » Thu, Oct 12, 2023, 5:03 PM UTC

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.

> no way I am going to write openapi spec

I don't get the stubbornness here. OpenAPI is not hard??? It's just JSON schema + some routes and effectively conveys the same information as a GraphQL schema, possibly more if you're not using custom directives and such.

> Then each side takes the contract and go implement the frontend and the backend and it just works

This is not unique to GraphQL. There's almost zero difference between programming to an OpenAPI spec vs a GraphQL schema - they're both API interface definitions.