pieces necessary to support it are in progress, but no firm timeline on it as of yet. I'm hoping we can get it scheduled formally soon though

What is the baseurl for a permission systems REST api?

Permission system is inferred from the referenced object types in the request

I'm getting a 405 which makes me think I am at the wrong baseurl here. https://app.authzed.com/organization//systems//v1/permissions/check

We don’t expose the rest gateway on authzed.com, for spicedb it will run on port 8080 by default

Gotcha, is the REST API limited to the on prem deployments then or is there something exposed for the SaaS tenants?

We haven’t enabled it because we haven’t had a request for it on the saas.

Is there a reason you need it instead of grpc?

Yeah, we have an IDP and want it to enhance token payloads with permission data from authzed. The IDP ootb supports configurable REST integration but not grpc.

I will bring it up at our planning meeting today and see what we can do

@User support for three character object types and relation names went out yesterday!

Thank you!

I was reading upon REST interface availability . Do we need to enable something on SpiceDB to make that available[gRPC gateway] . what is the URL pattern for the service request because the set-up does not have a tenant layer as it is in SaaS environment. http://localhost:8080/?/v1/permissions/check

@User run with

--http-enabled

and the REST gateway will be served by default on port

8443

. You can then make

POST

requests to `http://localhost:8443/v1/permissions/check`; make sure to include the preshared token as a

Bearer

in the

Authorization

header

i will put all this in my repos document side thank you

I noticed there isn't a Helm chart or Kubernetes manifests for spicedb in the authzed set of repositories. Do you guys plan on supporting a Helm chart in the future?

We do have a basic deployment, but it isn't one that clusters or has durable storage: https://github.com/authzed/spicedb/blob/main/k8s/basic.yaml

what would SpiceDB need the durable storage for?

Yeah, it doesn't really need durable storage, but you might prefer something like a StatefulSet to roll out the deployment with a strategy that might not cause all the caches to be emptied at once

gooot it. I imagine that the a rolling deployment strategy would cause unnecessary cache churn due to the rebalancing.

sorry, actually I think you are suggesting the opposite?

A normal kube deployment with perhaps

rollingUpdate

would cause the ring to be reshapped as new pods are rolled out and pods go down progressively

nope, you're right, you might be more conservative with your rollout if you want to avoid the churn from the caches rebalancing

Thanks for clarifying!

There's definitely work to be done there to improve the cache resilience

Have y'all ever considered decoupling the caches like the folks at AirBNB did with himenji? (I think that's the name?)

We're willing to maintain upstream a good example Kubernetes manifest that will help giving people a starting place, but not something that people should be using in production. I'm not sure if we want to adopt an opinion like Kustomize or Helm.

Yeah, it's a trade-off between simplicity of deployment vs resilience. I think we're confident that we can get to a place where SpiceDB is resilient enough that you shouldn't feel like you need to split out the caching from the orchestration.

agreed! I certainly favour less complexity, but it seems like it will move to that kind of architecture with the Tiger Cache right?