introduces bulk check permission API #75
Conversation
considerations: - does not reuse CheckPermissionRequest nor Response because a bulk check call requires a single consistency level and returns a single checked at zedtoken - gRPC map type does not support messages as key, so a repeated pair message is created - the response are pair items that include the request and the corresponding response, which would be either an error or a response item - two different APIs are introduced: one that streams responses as they are computed, and another one that blocks until all checks are completed. A client-streaming version was discarded for now.
| } | ||
|
|
||
| message BulkCheckPermissionRequestItem { | ||
| ObjectReference resource = 1 [ (validate.rules).message.required = true ]; |
There was a problem hiding this comment.
Was there any thought given to having these components be exploded/repeatable as well?
Then I could do things like:
check(document:1#read@user:(1,2,3,4,5))
or
check(document:(1,2,3,4,5)#read@user:1)
as part of a larger bulk check?
Basically I assume that a lot of bulk-checking use-cases would be bulk checking with most parameters fixed, and just one being "bulk". This API requires that you repeat yourself a lot.
There was a problem hiding this comment.
Yeah, I think that this API fits the simplest possible client logic (e.g. resources.map(x => x.proto())). It definitely uses more bandwidth, but I think it's a worthy tradeoff for UX.
I'd love to see how it plays out as an experiment and we can change it when if necessary.
Introduces Bulk Check API, which allows issuing multiple CheckPermission requests at once
considerations: