Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: Make Cache Management simpler for Multi Cache customers (#100)
* feat: Make Cache Management simpler for Multi Cache customers Currently the expectation from the customers is to have a Cache entity per each of their caches. Each cache entity is in turn tied to the GRPC channel to the SCS backend. So, we want customers to reuse their Cache entity. While this may be simpler for customers with a single cache, wherein they could simply create the Cache client once at the application start and inject into their code. This becomes significantly harder for customers with multiple caches since they now need to map cache names to correct cache clients and write their own registry. Simply creating a new cache client in application code will be very costly. Although the channel initialization etc. is handled lazily in the grpc layer usually first few cache operations can take longer. There are two ways to solve this problem: 1. Just provide a CacheClient which now is more of client than an entity. This client can take in cache name on each SET/GET request and then pass those transactions to the backend. This does come with the risk of CacheNotFound and PermissionDenied as CacheClients aren't now Cache entity specific. 2. The second approach is to separate the entity from the actual GRPC layer. The reason why Cache entity is costly right now is because of its tight coupling with the Grpc layer. While the risk of CacheNotFound and PermissionDenied still remains, it is now cheap to request Cache entity on each call as the grpc client will be shared amongst all entities. I have gone in with approach # 1. But can easily be convinced to go to # 1. Please take a look at the PR for a detailed discussion.
- Loading branch information