oh! i saw a

DispatchCheck

event in the logs while making requests. seems promising

Yep! if you see dispatch checks in the logs, they're dispatching you can also check the metrics

*_dispatch_*

to see how many of each call is dispatched, which ones are hitting the cache, etc

setting up metric collection is next up on the todo list and i will keep an eye out for that. thank you!

Hi folks! We're using Hasura as graphql server. We're using webhook pattern [1] to authenticate/authorize the gql query/mutation. I'm looking for recommendation on how to "introspect" the gql query easily—so we can have less accidental complexity, i.e. directly inputting the params for

check

SpiceDB queries. Here, you could imagine that the webhook server talks to spicedb via grpc every time there's a query/mutation. YSK: Hasura forwards custom request headers as well as the gql operation name and the query and its variables themselves. Thanks! 1. https://hasura.io/docs/latest/graphql/core/auth/authentication/webhook/

are you trying to find a way to map the resources requested by the query to resources in a check request?

Hi Jake, yes! 🙂

I'm planning to set up 2 kubernetes services:

spicedb-reader

which receives all

check

and

lookups

, and

spicedb-writer

which receives all

writeRelationships

and

deleteRelationships

. My goal is to avoid writes impacting read performances. Right now, I'm finding that even a low write traffic impacts read latency significantly. Is that a crazy thing to do, can you see a problem with that approach? Can I set

--datastore-readonly=true

for the reader instances, in this setup? I'm not clear on what this flag actually does

Have you measured anything that gave you the idea that write traffic affects request handling performance at all? My intuition is that handling the writes is not causing any issues, but rather that writes to the datastore do impact caching regardless of what server they take place on.

> Have you measured anything that gave you the idea that write traffic affects request handling performance at all Well, I've tested stopping the incoming writes on my system and observed that it improves check performances by ~30% (very rough numbers). > writes to the datastore do impact caching regardless of what server they take place on. Hmmmm interesting. Given that I'm not passing a zedtoken ever, I assumed that whatever happens in my writer instances shouldn't have any impact on my reader instances: the cache might be a few secs out of date but that's OK. Is this assumption wrong?

Morning 🙂 Has there been any interest in creating a spicedb persistence model that targets something like a bigtable or some other columnar store?

When SpiceDB picks a revision for you, it reaches out to the datastore to compute a optimal revision, which can change with both the wall-clock time, but also writes to the datastore.

Nope! But you should create an issue for it! If you're interested in GCP technologies, we do support Cloud Spanner, though. We use issues to gauge interest in functionality to develop

oh neat! I didn't see cloudspanner but I've not looked at docs in a bit. Last I saw it was in mem, crdb, or PG

I understand and that makes sense, but I had assumed that "optimal" accounts for what's already in cache. No need to fetch a more recent revision if the cache is still fresh enough, isn't it?

Somebody mentioned HBase recently, you can search for "hbase" in Discord

There's no concept of what exists in the cache already for picking an optimal revision. Here's a snippet of a talk one how SpiceDB picks its revisions optimally:

I'd probably need to watch the entire thing to really get it! But fair enough, I get the gist of it. Zooming out, going back to the root issue: the perf impact of writes on reads does seem weirdly oversized: my P50 on CheckPermissions is ~25% worse when there's some write traffic (6ms->8ms) and my P99 is almost double (76ms -> 140ms). Is that to be expected, or does it look shady? Maybe having some open-but-almost-unused gRPC connections for writes is impacting read latency somehow?

The P50 is small enough numbers that the percentage sounds drastic, but it's only 2ms in absolute terms. The p99 is including cache misses so it makes sense that it'd jump a bunch, but by how much I can't say for certain.

Where's the api documentation? The link does not work: https://buf.build/authzed/api/docs/main/authzed.api.v1

buf must have rolled out a change to their URL format

@User ^

@User Excellent. Thanks!

The https://docs.authzed.com/reference/api menu link must be updated

yeah, we'll check with the team over at buf to see if this is permanent or a mistake

hopefully not some april fools joke gone wrong

🙂

I am following https://docs.authzed.com/guides/first-app , Python flavor.

I have selected postgres as datastore.