[coffeedoughnuts]

> Using a normal restful HTTP api has none of these issues

I don't think a normal HTTP api provides anything to help with cache invalidation after a write operation, does it?

[simplyinfinity]

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET...

Etags can be used to check and invalidate content.

[timsuchanek]

Yes, but as long as a cached version is still returned at the edge (while the real content might have changed), the ETag won't help. It can only save you from unnecessarily downloading content you already have - in case it didn't change.

[simplyinfinity]

And when the content is updated you return different etag and the content is refreshed. Your system should have either distributed cache or a way for the edge to detect cache invalidations or for you to manually invalidate the cache on the edge.

[timsuchanek]

Exactly, that is what we provide. Including Etag support btw.

[doteka]

As other commenters have mentioned, in fact it has functionality specific for this purpose. That is part of the underlying reason for my question: it often feels like the people pushing for graphql adoption are not aware what http is capable of out of the box.

[timsuchanek]

+1