Closed piemanvik closed 8 years ago
Hi,
The server scenario of CacheCow works on pure REST APIs where the resource changes only through the API. Three years on after building the library, I feel pure REST APIs are much rarer than I thought.
The option you have is use the IEntityTagStore interface methods to invalidate resources that change in the background - such as Remove or RemoveAllByRoutePattern. This is not ideal but I guess is the only option available.
Hope this helps
Hello, yeah people like to build on older technologies .. hit that resource database from willy nilly code, it is sad really.
So basically I need to first deduct server side if a resource has changed by implementing some service that does this before CacheCow gets to do things. And if it has changed then I use IEntityTagStore to do proper invalidation and then move on with normal pipeline. If not then I just continue.
Alas this would make the server always execute some code for the deduction... but at least the payload will be smaller on client side.
Thank you.
Sure! And thanks for using CacheCow. :+1:
Hello,
Scenario:
Currently as I see it CacheCow will not know that the resource has changed and will always spit out 304. I understand that this is how it is supposed to work .. and it is awesome however how do I deal with the scenario when other 3`rd party apps change data in my database that do not go through my api endpoint that uses CacheCow logic ?
Thank you.