there is discussion for a better file format for both export and import

how does one export SpiceDB everything?

currently

ReadRelationships and ReadSchema

but is the intent for backup or... ?

i would have used to upgrade 1.13 -> 1.14

export data from v1.13 into a "spicedb file," upgraded the server, then loaded the previously made export into v1.14

I'm not sure I follow why you'd need to do that... you can just run

spicedb migrate head

to have SpiceDB upgraded

or are you talking about a different use case?

are all versions forward compatible

?

versions of... what, exactly?

can datastore from SpiceDB version X always be always directly migrated to Y, if Y > X? i thought that you do not guarantee this.

it can be migrated with brief downtime, yes

i did not realize

if you want to do it with no downtime, you need to go version-by-version

(except when documented)

downtime is fine

okay

then its simple: take the cluster offline, run

spicedb migrate head

with your datastore flags on the new version, bring it back up on the new version

qq: Has anyone established patterns for "frontend" integrations, eg in React/etc As an example, say there is a . It can either be Visible, Not Visible, or Visible but Disabled, depending upon different Permissions. In some previous work which was not as fine-grained as Zanzibar systems, I've made React Components like </ which would Hide its children if the User didn't have a permission (which was generally a List of Strings/IDs, attached to the React Context, which we set on App initialization). Similar thing for properties like Disabled=true on a component, just a react func that returns bool (useHasPerm(someConst). Obviously running the full "calculation" on the frontend doesn't seem viable :). (even with all the cool kids running SQLite on the frontend with WASM) Is the best practice re-exposing a sub-set of the SpiceQB queries over my API Surface, and injecting the User identity there to ask Questions? Eg, some kind of API for Permission Checking the frontend can call alot, which mostly just proxies to a spicedb call?

I will leave it to @Joey for the real answer here, but yes your intuition is correct, you'll want to have your backend either re-expose SpiceDB as a new API (after verifying identity of the caller) or you'll want to just preload the right things and send them with the page context

the general recommendation today is to issue a series of checks on the backend and send the results to the frontend for rendering

longer term, we have some ideas around how this might be more directly exposed, especially given frontend frameworks that support backend JS as well. Are you by chance using NextJS?

Yes, we do use Next.js, but we do not host on Vercel. And our Next.js App has no "backend", its kinda just a "SPA-loader", heh.

nothing wrong with that 🙂

I have a prototype I hacked up that provides hooks for retrieving permissions for this exact use case

the basic idea was you decorated the

getServerSideProps

with the set of permissions you wanted checked, then they were issued and the results were placed into the

props

for the page

so you could render UI accordingly

an API driven approach would work as well, of course