REST vs GraphQL vs gRPC
danhacks.com
REST vs GraphQL vs gRPC
1–10 of 168 posts
Re: REST vs GraphQL vs gRPC
#2Too concise. This wouldn't be helpful for making a choice; or will mislead. Right off the top, it's not necessary to write REST endpoints for each use case. Many REST apis have filtering and joining, just like gql.
Edit: claiming gql solves over/underfetch without mentioning that you're usually still responsible for implementing it (and it can be complex) in resolvers is borderline dishonest.
Re: REST vs GraphQL vs gRPC
#3Too concise. This wouldn't be helpful for making a choice; or will mislead. Right off the top, it's not necessary to write REST endpoints for each use case. Many REST apis have filtering and joining, just like gql. Edit: claiming gql solves over/underfetch without mentioning that you're usually still responsible for implementing it (and it can be complex) in resolvers is borderline dishonest.
I'd call it completely lacking, not concise. E.g. its already conflating transport & serialization. But HN loves a good serializer debate so this will be an active thread.
Re: REST vs GraphQL vs gRPC
#4One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. gRPC using protobuf means you get actual typed data, whereas typing in JSON (used by the other two) is a mess (usually worked around by jamming anything ambiguous-in-javascript like floats, dates, times, et c into strings).
If you're using typed languages on either the client or the server, having a serialization system that preserves those types is a very nice thing indeed.
Re: REST vs GraphQL vs gRPC
#5One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. gRPC using protobuf means you get actual typed data, whereas typing in JSON (used by the other two) is a mess (usually worked around by jamming anything ambiguous-in-javascript like floats, dates, times, et c into strings). If you're using typed languages on either the client or the server, having a seria…
> usually worked around by jamming anything ambiguous like floats, dates, times, et c into strings
because nobody has ever done this with protobuf...
btw what is the protobuf standard type for "date"?
Re: REST vs GraphQL vs gRPC
#6Not loading for me (PR_CONNECT_RESET_ERROR on Firefox, ERR_CONNECTION_RESET on Chrome).
https://web.archive.org/web/20210315144620/https://www.danha...
Re: REST vs GraphQL vs gRPC
#7Too concise. This wouldn't be helpful for making a choice; or will mislead. Right off the top, it's not necessary to write REST endpoints for each use case. Many REST apis have filtering and joining, just like gql. Edit: claiming gql solves over/underfetch without mentioning that you're usually still responsible for implementing it (and it can be complex) in resolvers is borderline dishonest.
I'd call it completely lacking, not concise. E.g. its already conflating transport & serialization. But HN loves a good serializer debate so this will be an active thread.
Must be a bad student homework ...
Re: REST vs GraphQL vs gRPC
#8One thing that people seem to gloss over when comparing these is that you also need to compare the serialization. gRPC using protobuf means you get actual typed data, whereas typing in JSON (used by the other two) is a mess (usually worked around by jamming anything ambiguous-in-javascript like floats, dates, times, et c into strings). If you're using typed languages on either the client or the server, having a seria…
> usually worked around by jamming anything ambiguous like floats, dates, times, et c into strings because nobody has ever done this with protobuf... btw what is the protobuf standard type for "date"?
int64 representing unix epoch millis (in UTC) is what I usually use. You need to jump through an additional hoop to store timezone or offset.
You can, of course, do the thing that JS requires you always do and put an ISO8601 date in a string. This has the benefit of storing the offset data in the same field/var.
Javascript needs int64s as strings, I believe, because the JS int type maxes out at 53 bits.
Re: REST vs GraphQL vs gRPC
#9[deleted]
Re: REST vs GraphQL vs gRPC
#10Am I the only who simply does remote procedure calling over http(s) via JSON? Not REST as in resource modelling but simply sending a request serialized as a JSON object and getting a response back as a JSON object.