Understanding the concepts behind asynchronous messaging
Understanding the concepts behind asynchronous messaging
I am speaking at Build Stuff 2023 next week and my session is "REST, gRPC & GraphQL - A Comparison". This article is a supporting resource for my session.
This is the last article in the series - REST, gRPC and GraphQL. You can read the other parts here.
The three API paradigms can be compared on many points. I have listed my findings into points below.
REST - Resources
gRPC - Functions
GraphQL - GraphQL Query
REST - Usually XML/JSON
gRPC - Protobuf (binary), can be JSON
GraphQL - JSON
REST - Low (if HATEOAS is implemented by the server and used by the client)
gRPC - Medium
GraphQL - Very low
REST - High
gRPC - Medium
GraphQL - Low
REST - Good with HATEOAS
gRPC - Bad
GraphQL - Good
REST - Can be needed
gRPC - Can be needed
GraphQL - Not necessary
REST - Stateless
gRPC - Stateful (Streaming over HTTP/2 can be considered stateful)
GraphQL - Subscriptions are stateful, not queries or mutation
REST - High
gRPC - Medium
GraphQL - Light/Can depend on the query
REST - Yes
gRPC - Bad, unsuitable for browser-based apps as native gRPC
GraphQL - Yes
REST - No
gRPC - Yes
GraphQL - Yes
REST - Mature
gRPC - Evolving
GraphQL - Evolving. Many developers start as consumers of GraphQL than implementing a GraphQL API
REST - Medium
gRPC - Medium
GraphQL - Steep
REST - Huge amount of resources available
gRPC - Fewer compared to REST
GraphQL - Fewer compared to REST
Understanding the concepts behind asynchronous messaging
This article discusses some of the misconceptions about REST, and what is not REST and presents you with the facts.