Initial implementation of request cache #223
Conversation
rkuris
force-pushed
the
rkuris-request-cache
branch
2 times, most recently
from
a8a7192
to
9b02478
Compare
rkuris
force-pushed
the
rkuris-request-cache
branch
from
9b02478
to
6c37ea8
Compare
|
|
||
| // CacheableContext produces a context that has a cache in it | ||
| // from one that does not | ||
| func CacheableContext(ctx context.Context) context.Context { |
There was a problem hiding this comment.
tl;dr I don't like this, but I can't think of a better solution, so let's go with this for now.
I think this is the one big problem I have with this design. In the application code, where do we call this function? I probably have to call it in my handler code, immediately when I first receive the request. That's what I'd have to do in order for this context to be used over the entire duration of the request. But now I've got a call to my Datastore logic all the way up in my handler. That seems like a leaky abstraction. If I change my datastore implementation, I'm now going to have to change my handler logic. This tightly couples the business logic to DOSA.
Also, It's not immediately obvious to me that if I'm using the RequestCacheConnector that I also need to use this special context creation function (or else the connector doesn't do anything). This violates the Principle of Least Astonishment.
The context, when it first arrives in the handler, is really the only thing whose lifecycle appropriately parallels the lifecycle of the request. I think what I'd like ideally is that the first time the connector sees the context, it initiallizes the cache and attaches it to the context. Then, in all subsequent requests the connector will see that a cache has been created and just use the existing one on the context. But I don't think that's possible given the way Context interface works.
|
|
Still needs some docs, and we need to include this automatically with NewClient, but that will be done under a different PR.