gRPC and caching?

[Dmitri Shuralyov]

Hi,

I'm a little surprised to find very little on the caching story of gRPC. What is the current status? If I'm not mistaken, it seems to be "exercise left to reader" to add some sort of caching support on top of gRPC (in contrast to authentication, which is described here), is that so?

Suppose there is a service that has a Get-like method. This method implementation performs some relatively expensive io and returns a lot of data to the calling client. If the information doesn't change often and it's expensive to return raw results each time, it seems one would benefit from having caching so the server can respond the equivalent of "304 Not Modified" of RESTful APIs.

It seems quite doable to implement a caching system by making use of gRPC metadata. But before I start doing that, I wanted to check in here. Perhaps the reason there's little information on caching with gRPC simply because it's very new and it hasn't been done yet? Or am I missing some relevant information on why this is a bad idea and shouldn't be done?

Thanks!

[Nicolas Noble]

I would say that this isn't really something we would like to introduce in the core of grpc. It is indeed left as an exercise to the reader in the sense that it is rather something that you would implement in your messages.

Not all kinds of rpc would find that feature relevant, so let's not make all of them pay its cost on the critical path. Authentication on the other hand is on the channel itself, and the presence of the code won't impact non-authenticated channels.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5e7b9db1-d7f5-41d0-a5f4-ddbf5fcd3d02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Craig Tiller]

Not to contradict Nicolas, but :) we have talked a little about what a caching layer for grpc would look like. It's a little outside of our core use case, and definitely in the realms of experimentation being required. If you have ideas I'd encourage you to prototype them and see if something awesomely useful falls out.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEvr0PFmeuzX6fHB5Aiq4aEBcmX25gUcvAZNc1%3DTbhrj5_VU1w%40mail.gmail.com.

[Nicolas Noble]

I don't think I remember that discussion! Bah ;-)

I guess my stance still stands, kind of: this is outside the normal functionalities of our core use case. I wasn't completely wrong :P

[s...@sourcegraph.com]

I have a proof-of-concept gRPC caching wrapper for Go at https://sourcegraph.com/sqs/grpccache. It uses codegen (wrapping each Client with methods that perform caching) and passes HTTP-like Cache-Control directives over gRPC metadata. It only supports max-age right now.

Posting it in case it is useful/interesting to other folks.