search

aliostad / CacheCow

An implementation of HTTP Caching in .NET Core and 4.5.2+ for both the client and the server
MIT License
848 stars 171 forks source link

0.6.3 to 2.11.3 Migration - Replacement for IRoutePatternProvider? #291

Closed RyanLamanskyInsite closed 1 year ago

RyanLamanskyInsite commented 1 year ago

It looks like there have been some breaking changes but it's not obvious what the replacement for IRoutePatternProvider is. The app I'm working on uses it for complicated invalidation rules. How do I convert that to the current method?

aliostad commented 1 year ago

Hi,

Sorry this has been removed. This was based on the a flawed presumption which a resource is only changed via its API while it might have been changed without an API call. Even if it is only changed via API call, it was a constant battle to get that working and it was becoming more and more complex.

The replacement is not so much simpler but more robust and trustworthy.

This explains it here - although I do not know if anyone uses it in production.

http://byterot.blogspot.com/2018/05/cachecow-20-is-here-supporting-netcore-netstandard-aspnetcore-httpclient-aspnetwebapi-etag.html

This section explains it:

CacheCow.Server has changed radically

The design for the server-side of the CacheCow 0.x and 1.x was based on the assumption that your API is a pure RESTful API and the data only changes through calling its endpoints so the API layer gets to see all changes to its underlying resources. The more I explored and over the years, this turned out to be a pretty big assumption in the end, and is realistic only in the REST La La Land - a big learning for me. And even if the case is true, the relationship between resources resulted in server-side cache directive management to be a mammoth task. For example in the familiar scenario of customer-product-orders, if an order changes, the cache for the collection of orders is now invalidated - hence the API needs to understand which resource is collection of which. What is more, change in customer could change the order data (depending on implementation of course, but just the take it for the sake of argument). So it meant that the API now has to know a lot more: single vs collection resources, relationship between resources... it was a slippery slope to a very bad place.

Hope this helps.

Cheers Ali

aliostad commented 1 year ago

By the way the replacement is explained in this post and there are a number of samples

http://byterot.blogspot.com/2018/06/cachecowserver-20-using-it-on-aspnetcoremvc-dotnetcore-etag-http-caching-aspnetcore.html