Re:Show HN: REST Alternative to GraphQL and tRPC
by chrisweekly on Tuesday October 10, 2023 @09:51AM
(#37832101)
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
by nine_k on Tuesday October 10, 2023 @05:41PM
(#37837974)
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?
Re:Show HN: REST Alternative to GraphQL and tRPC
by rattray on Tuesday October 10, 2023 @05:51PM
(#37838105)
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).
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.