Is the Playground having issues? I've got a simple schema that works as intended in the playground but the moment I try to import it into authzed, it fails with message "failed when contacting upstream gRPC service". Definition here: https://gist.github.com/Vannevelj/69c56fa209fd0b0c660490bf8c945da6

it looks like even though an error message is displayed, the import does still work. can you check the schema in authzed.com and make sure it was saved?

There's no schema for me. My tenantID is

O8HaL

according to the GraphQL call if that helps

just noticed that you have multiple prefixes in your schema - in authzed.com, you can only have 1 prefix (i.e.

gsl

and

hudl

) in your schema per permission system

Ok I see. We have tested it using 1 prefix it works.

Great!

When you say

in authzed.com, you can only have 1 prefix

does this mean website or will the dedicated server also have this limitation?

Just the hosted authzed.com solution. Dedicated has no prefix restrictions

Ah I see. Is there anything in the works to make authzed.com also support multiple prefixes?

we do have plans for that, but not in the short term if you want prefixes in authzed.com right now you do have a couple of options: 1. make different permission systems with different prefixes (this will work as long as you don't need to have relationships between the objects in each system) 2. use a different character to separate, i.e.

myprefix/hudl_user

and

myprefix/gsl_team

, etc

Option 1 isn't a possibility for us so we'll be going with #2. Are there any other schema limitations that we should be aware of? We plan to use SpiceDB dedicated for our prod data and authzed.com for our test environment (for now), so we need to build it according to the lowest common denominator.

the primary difference between the authzed.com deployment of spicedb and the dedicated version is the tenancy layer in authzed.com, you can't use multiple prefixes because the service uses prefixes for tenant isolation on shared infrastructure, but in dedicated you can. this also means that the extra token management you get in authzed.com isn't there in dedicated, which uses preshared keys like upstream spicedb. this will be replaced with better token management soon, but right now it's a difference from the hosted authzed.com version. the only other differences are resource related; in dedicated we can tailor rate limits / request size limits for you (or remove them entirely), whereas hosted authzed.com may limit you more.

That's interesting. We're doing it as Dedicated+SaaS because we want the test environment to be entirely isolated from Prod and I was under the impression that they would share the physical hardware even if we did a logical split at the permission system level. You're saying that we can have it fully separated? To that end, we also have our test and prod environments running in separate VPCs -- would the dedicated solution require access to both?

> You're saying that we can have it fully separated? You can have them completely isolated if you like, but you do have to pay for more physical resources. Logical isolation is "free" in the sense that you just lose some of the existing cluster's capacity. > To that end, we also have our test and prod environments running in separate VPCs -- would the dedicated solution require access to both? You would peer each vpc with the region's PrivateLink (assuming AWS). so if you had separate regions for test/prod, you'd just peer your test vpc with the test region and the prod vpc with prod region(s)

Okay, I might ask some clarification around this when we get to discussing the contract. We'll reach out about that in due course, right now we'll try out a schema on SaaS and see where we get with our implementation

sounds good, please reach out if you hit any issues or have any questions