Hi, I have a question on check request with the go grpc client. The documentation is telling me that all the parameters of a request are deprecated. What am I supposed to use here? https://www.ory.sh/docs/keto/reference/proto-api#checkrequest-1 You still seem to be using them here: https://github.com/ory/keto/blob/6c0e1ba87f4d3a355cebd0ea77f28319be2dd606/cmd/check/root.go or here: https://github.com/ory/keto/blob/6c0e1ba87f4d3a355cebd0ea77f28319be2dd606/internal/e2e/grpc_client_test.go The above implements an interesting interface here: https://github.com/ory/keto/blob/6c0e1ba87f4d3a355cebd0ea77f28319be2dd606/internal/e2e/full_suit_test.go which seems super useful. Wouldn’t it make sense to have a wrapper client like that for all the connection boilerplate and make it part of the official package, instead of only having it in the test suite?

Hi, the

tuple

field is not deprecated, but it's hard to see because the docs look somewhat mangled. @steep-lamp-91158 do you know what's up with that? Regarding the wrapper, that sounds like a good idea, but needs some more analysis. Most of the boilerplate that is abstracted away in the test clients is • where to connect to • how to do pagination • how to do error handling I'd assume that most applications want to customize these things, so the boilerplate is actually warranted. WDYT?

Hmm, I mean it’s fair to assume most people who would be using the gRPC API with your managed service would be using it exactly like you have it implemented in the test suite. The where and pagination could be just a parametrization imo. As for errors, you could just bubble errors up through any wrapper client functions. You would make it easier to use your product. I plan to host keto myself, once I get familiar with it, but that’s a different story. And the only thing that would change from my POV is the credentials part. On my Kubernetes cluster I most likely won’t use the token.