if they are all different, then there isn't really a benefit

gRPC makes parallel requests across the same connection

so a batch permission check wouldn't really add much value

Well the database could do all of the work and return 1 result instead of processing many individuals.

not really

that's why I asked whether they were different permissions

if they are different permissions, then different paths in the schema have to be followed

in a hypothetical batch solution, the checks would either have to be run in sequence or parallelized by the server

but

since gRPC is already parallel

you can just run them yourself in parallel

and there should be very little difference

(maybe a tiny bit of overhead on the gRPC back and forth, but I doubt its meaningful in most case)

consider the scenario where you're making these three calls:

check document:firstdoc view user:symion
check document:secondoc edit user:tom
check document:thirddoc can_admin user:sarah

they are each on different resource IDs, so they'd start with different queries in the datastore

they are on different permissions, so they have to start at different places in the graph

and they are for different subjects, so they perform different relationship queries

the only benefit to sending that as a single batch request would be to eliminate some of the overhead in the gRPC transport, as I said, but those are unlikely to have a major impact in the common cse

case*

now if the permission and subject are the same, then yes, a batch call does make a lot of sense

which is actually how check works internally when it can do so

but I'm unsure how helpful that would be exposed in the API

and the major downside of having them be batched into an API call is that you're hitting a single node for the initial request

vs if you run them in parallel for the client and hit 3 different nodes, you scale a lot better

for 3 checks, not appreciably different; for 300 it could be

are the

spicedb_dispatch_client_cache_*

metrics an indication of if spicedb is reading from cache.

the client side cache, yes

even when I hammer on it with permission checks, those metrics never seem to tick

a few things to remember about the cache: 1) there are two caches, one client and one server side and you need the dispatch enabled on the cluster to get good use of them 2) the caches are bound by the memory given to them and will evict if there isn't room 3) the caches are only used within a quantization window period, which is by default ~5s

"client" and "server" being within SpiceDB; before and after dispatch, respectively