One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
If you are doing REST, you can ignore my snarky comment and read the fine article instead.
For GraphQL specifically, Facebook took the somewhat controversial decision to throw away all HTTP codes and verbs and server-side caching mechanisms. Everything is a POST { "query": "graphql query", variables: { json } } to example.com/graphql and returns HTTP 200 OK. Exceptions and failures are treated via another mechanism. Caching... who needs caching?
Thanks for sharing this @jmfayard, I have only worked with REST APIs, so this is mostly about it, but I am glad that now the readers can understand the context for GraphQL from your comment as well.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
@jmfayard isn't a world without errors the one we want? 😂
At the end is a design decision and you can use it or not. Apollo sure has some errors available. Got your point anyway 😁
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I think the way graphql handle errors is surprising at first but fine in the end.
On the other hand the decision to just disregard the built-in HTTP server side caching is IMHO very questionable.
Depending on your use case, that may be a reason to prefer to stick to REST.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
On the other hand the decision to just disregard the built-in HTTP server side caching is IMHO very questionable.
In an endpoint-based API, clients can use HTTP caching to easily avoid refetching resources, and for identifying when two resources are the same.
The URL in these APIs is a globally unique identifier that the client can leverage to build a cache.
In GraphQL, though, there's no URL-like primitive that provides this globally unique identifier for a given object. It's hence a best practice for the API to expose such an identifier for clients to use. source
You can extend that to specific fields easily instead caching the whole response, see example
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I use HTTP 200 everywhere because Facebook says it's the best practice now #graphql
eeew
Source please?
If you are doing REST, you can ignore my snarky comment and read the fine article instead.
For GraphQL specifically, Facebook took the somewhat controversial decision to throw away all HTTP codes and verbs and server-side caching mechanisms. Everything is a
POST { "query": "graphql query", variables: { json } }to example.com/graphql and returnsHTTP 200 OK. Exceptions and failures are treated via another mechanism. Caching... who needs caching?See for example 200 OK! Error Handling in GraphQL and serving GraphQL over HTTP
Thanks for sharing this @jmfayard, I have only worked with REST APIs, so this is mostly about it, but I am glad that now the readers can understand the context for GraphQL from your comment as well.
@jmfayard isn't a world without errors the one we want? 😂
At the end is a design decision and you can use it or not. Apollo sure has some errors available. Got your point anyway 😁
I think the way graphql handle errors is surprising at first but fine in the end.
On the other hand the decision to just disregard the built-in HTTP server side caching is IMHO very questionable.
Depending on your use case, that may be a reason to prefer to stick to REST.
In an endpoint-based API, clients can use HTTP caching to easily avoid refetching resources, and for identifying when two resources are the same.
The URL in these APIs is a globally unique identifier that the client can leverage to build a cache.
In GraphQL, though, there's no URL-like primitive that provides this globally unique identifier for a given object. It's hence a best practice for the API to expose such an identifier for clients to use.
source
You can extend that to specific fields easily instead caching the whole response, see example