4 ms·
> 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 oper
by coffeedoughnuts 5y ago
> 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?
- timsuchanek 5y ago+1
- simplyinfinity 5y agohttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET... Etags can be used to check and invalidate content.
- timsuchanek 5y agoYes, 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 5y agoAnd 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 5y agoExactly, that is what we provide. Including Etag support btw.
- doteka 5y agoAs 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.