This seems to help:

#!/usr/bin/env -S buf generate buf.build/authzed/api:7a18d413329a4f4fb0c4237afb640e8e --template
---
version: "v1"
  # The plugins to run.
plugins:

    # The name of the plugin.
    # Required.
    # By default, buf generate will look for a binary named protoc-gen-NAME on your $PATH.
  - name: ts

    # The the relative output directory.
    # Required.
    out: gen/ts

    # See "available plugin parameters"
    # https://github.com/timostamm/protobuf-ts/blob/master/MANUAL.md#the-protoc-plugin
    opt: generate_dependencies,long_type_string

    # The custom path to the plugin binary, if not protoc-gen-NAME on your $PATH.
    # Assuming you have installed @protobuf-ts/plugin in the working directory:
    path: ./node_modules/@protobuf-ts/plugin/bin/protoc-gen-ts

@User I don't know specifically that Google uses Zanzibar for GCP, but I was able to model something that might be helpful to you https://play.authzed.com/s/1wtA0bW0NJ2F/schema

let me know if you have any questions or want help tailoring it to your use case

yes, that's the exactly correct design

SpiceDB isn't stateless, because it does have local caching, but if you send ZedTokens or use consistency: full as options, it will always go to the database

@User I'll be taking a look at the Typescript stuff today; thanks for the starting point!

Hi folks, might be wrong, but every request to the spicedb is establishing a new grpc connection, using the golang client at least. Is there a reason for this? or any options to keep connection alive, for lower latency requests?

The go client should keep a single long-running connection. Are you initializing a new client for every call?

hmm nope, shouldn't do, let me double check that

actually, i might be wrong i think i wrote some code for client-side pooling and it did not make a difference in performance

Since gRPC is http2 and can already send multiple requests over a single connection, pooling connections isn't useful

but that single connection should be long-lived with the client, and if it's not, it's probably a bug (either in your code or gRPC)

kind of related question, does the client provide any functionality on top the basic generated grpc client?

Not really, the code is quite short: https://github.com/authzed/authzed-go/blob/main/v1/client.go

ok, cheers

We want to try and get rid of some of the boilerplate, but want to enable folks (and ourselves haha) to re-use the nice gRPC libraries for any additional behavior

Have there been any discussions around supporting tenant isolation at the database layer in spicedb (a single database instance but database or schema per tenant)? How do you guys handle multitenancy in the cloud offering? I'm assuming you host an instance per tenant based on the support in spicedb today. I'm interested in using spicedb but I have use cases where tenants want database level isolation. I also have some use cases where tenant isolation is valuable because of the sheer volume of permission relationships that exist in one tenant vs another. Curious if ya'll have started any discussions/ideas around that, or if you have a hard stance on not supporting that etc..

I think for now, we consider Authzed's tenancy implementation WIP. We've made changes to SpiceDB in the past that dramatically alter it and I don't really expect those kinds of changes to stop in the near-future. I do think that it'll find its way open source as some form of middleware in SpiceDB. I was actually just having a discussion with @User privately about how the dashboard built into SpiceDB might eventually need tenancy functionality to implement more advanced features.

@User it'd be nice for you to write up a detailed use case for what you want to see out of it for use at Adobe. Your usage might differ from Authzed.com.

Another option could be in the short term signing something with Adobe and share some of the Authzed internals as we flesh it out, so that ya'll have early access.

👍 I'll write some use cases up and we can go from there.

Here are those use cases: https://github.com/authzed/spicedb/issues/204

hi folks, sorry, another question, considering the relation tuples table in db always grow, as deleted relationships are not removed, any recommendations re. maintaining these to keep performance on the long run? I'm thinking table partitioning. Thanks

in particular if DB is postgres

Postgres does have garbage collection now: https://github.com/authzed/spicedb/pull/168

This just hasn't shipped in an official release yet.

Nice!