Hacker News Reader

Comment by itake | Hacker News Reader

You can still design an immutable REST api to match the client's needs. Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.

I see your point about reducing network requests (graphql lets you co-mingle mutations and queries), but I don't think that feature is used often enough, b/c what if one query fails, then everyone has to fail).

View on HN

> Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.

Caching is trivial to do with REST.

The "really nice caching" that Apollo does literally deserializes and deep inspects both the request and the response to try and figure out caching on specific fields. Also, POST requests are not cacheable according to HTTP spec.

With REST you set an ETag and/or Cache-Control headers and let your existing infra and client browsers handle that.

You can make a REST endpoint match a client's needs, but if you have multiple clients (for example, 1 for mobile and 1 for desktop) that all need different amounts of data (for example, the mobile client shows a simplified view with less data), then you would need to write 2 different REST endpoints to handle each clients. Multiply that by the number of pages with a difference.

> then you would need to write 2 different REST endpoints to handle each clients.

Or you use Accept header for its intended purpose

Accept: com.company.user-aggregated/json

Accept: com.company.user-aggregated-lite/json

etc.

And let the server return the fields defined by the relevant schemas.

I mean, the advise given for GraphQL in prod is to literally call predefined queries only.

Reply on news.ycombinator.com