Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write API: make TupleKeys more canonical #79

Open
jon-whit opened this issue May 15, 2023 · 0 comments
Open

Write API: make TupleKeys more canonical #79

jon-whit opened this issue May 15, 2023 · 0 comments
Labels
breaking-change Will result in a breaking change to the API enhancement New feature or request

Comments

@jon-whit
Copy link
Member

jon-whit commented May 15, 2023

Today the Write API looks like:

message WriteRequest {
    string store_id = 1;
    TupleKeys writes = 2;
    TupleKeys deletes = 3;
    string authorization_model_id = 4;
}

message TupleKeys {
    repeated TupleKey tuple_keys = 1;
}

message TupleKey {
    string object = 1;
    string relation = 2;
    string user = 3;
}

The usage of TupleKeys is completely unnecessary and makes the API and related code stutter. For example in Go code we have:

tupleKeys := openfgapb.TupleKeys{
    TupleKeys: []*openfgapb.TupleKey{...}
}

I propose we make this more canonical with simply:

message WriteRequest {
    string store_id = 1;
    repeated TupleKey writes = 2;
    repeated TupleKey deletes = 3;
    string authorization_model_id = 4;
}

and the corresponding code in Go will simply look like:

tupleKeys := []*openfgapb.TupleKey{...}

Note that these changes are a breaking change to the API though. The HTTP request body and gRPC request bodies change in an incompatible way.

{
    "writes": {
        "tuple_keys": [...]
    },
    "deletes": {
        "tuple_keys": [...]
    }
}

becomes

{
    "writes": [...],
    "deletes": [...]
}
@jon-whit jon-whit added enhancement New feature or request breaking-change Will result in a breaking change to the API labels May 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Will result in a breaking change to the API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant