openfga / api

Protocol Buffers used by OpenFGA
Apache License 2.0
18 stars 10 forks source link

feat: add new API definitions for relation metadata & assignable types #27

Closed jon-whit closed 2 years ago

jon-whit commented 2 years ago

Description

This starts the beginning of a new OpenFGA model package v2beta1 which contains the preliminary definitions for the type info in TypeDefinitions.

References

Review Checklist

jon-whit commented 2 years ago

The idea here would be use to v2beta1 to support the new TypeDefinition structure and once the old structure is deprecated we can remove it strictly in favor of the v2beta1 defininitions.

If the v2beta1 definitions stick long enough for us to commit to long term maintainability, then we can cut v2beta1 under an official v2 in the future.

@rhamzeh I recognize the impact of this on SDKs and tooling, but I think it's warranted to make the model of a TypeDefinition more clear and it also supports our use case for ListObjects more accurately.

Code in the server becomes:

typedef := datastore.ReadTypeDefinition("document")
relations := typedef.GetRelations()

relation, ok := relations["viewer"]
if !ok { // relation doesn't exist }

typeinfo := relation.GetTypeInfo()

What do you think? Can we proceed with this approach?

craigpastro commented 2 years ago

By the way, should we bring all the proto files to v2beta1 so we don't need to have two imports everywhere?

jon-whit commented 2 years ago

By the way, should we bring all the proto files to v2beta1 so we don't need to have two imports everywhere?

Not all of them. If we evolve our grpc service API definitions then we can start a new openfga.v2beta1.OpenFGAService at a later date. For now I think it makes sense to have separate API definitions since they are under different packages. If we have a shared package between the two we can create a shared package instead.