search

nefarius / Nefarius.HttpClient.LiteDbCache

Adds disk-based response caching to HttpClient named instances using LiteDB.
MIT License
1 stars 0 forks source link

Some design considerations #9

Open bugproof opened 8 months ago

bugproof commented 8 months ago

I made something similar in my project based on sqlite but in my use case I still want to return cached response even if request fails so when the external API is not responding your app still works with a cached data. Another design consideration is not depending on sqlite/litedb but on some storage abstraction like https://github.com/robinrodricks/FluentStorage or a custom interface. So you can have HttpClient caching with a storage solution of your choice so you can even store JSON files in a local directory/ Amazon S3 etc.

I considered LiteDB at first but it didn't support async (apparently the author is working on adding async in LiteDB 6)

nefarius commented 8 months ago

I made something similar in my project based on sqlite but in my use case I still want to return cached response even if request fails so when the external API is not responding your app still works with a cached data.

The initial design criteria for this library was to make an application offline-capable, so the assumption is that at one point there has to be availability of the cached Web API at least once, then after the cached response(s) were successfully cached, the caller can configure them to remain in cache for days or weeks even.

Another design consideration is not depending on sqlite/litedb but on some storage abstraction like https://github.com/robinrodricks/FluentStorage or a custom interface. So you can have HttpClient caching with a storage solution of your choice so you can even store JSON files in a local directory/ Amazon S3 etc.

That's a very cool project, I'll definitely remember to check it out if I need something more sophisticated 👍

I considered LiteDB at first but it didn't support async (apparently the author is working on adding async in LiteDB 6)

The only thing I might consider missing is cancellation support, otherwise we have to wait on file I/O anyway so that wasn't really a showstopper for me. But interesting to know that they consider adding that 👍

All in all I consider this project mostly feature-complete, to support more backends I'd either plan that as a new major release or a new independent project entirely.

Cheers