I licensed ServiceStack.Redis after moving from StackExchanges implementation a while back. I built a nice internal nuget package around it to fit a particular need but it now needs to be expanded upon. The lib supports the concept of “friend” apps which allow either read, write or read/write access to each others redis store which is isolated by DBID. Up until now each app has been happily playing in its own sandbox, each having their own DB. Without going into great detail, this is a very large web API and is currently using autofac for its container.
I started down the road of simply having separate registrations for each DB that an application is “friends” with in this larger, micro service architecture and instead of injecting my redis factory wrapper where needed it instead passed along a redis DB manager which contained the collection of the factories. I then got to wondering if there wasn’t a better way which is already implemented in the ServerStack.Redis library itself as multiple redis connections, even to different redis instances cannot be that uncommon a problem.
That said, has anyone come up with a good pattern or know of a way of doing this natively with the pooled connection manager?
If the same app uses a custom db then you can configure your Redis ClientsManger with the db you want, otherwise you can either maintain a high-level API which sets the DB on the client connection before returning it to your App.
The alternative is for your high-level API to maintain multiple singleton instances of Redis Clients Managers all configured to different Redis DB’s which your high-level API would use to return a connection to the right db. If your Redis DB’s are on different Redis instances you’ll need to maintain multiple Redis Client Managers.
Currently my RedisCacheManager (my implementation) takes in a connection string which includes the dbId (using Azure redis but not important). In this particular case, one of the apps (lets say the web API which “owns” db 0 needs to write a value into db 1, owned by another app (microservice). The road I was going down and I believe you are likewise advocating is maintaining multiple singleton’s all hidden away in my manager and then simply selecting the correct instance when accessing redis. I was almost done with this implementation when I wondered if there was not a way to do this already built into the servicestack.redis lib. It is clean but I did not want to reinvent the proverbial wheel if I didnt need to.