openfga / openfga/api

Write API: make TupleKeys more canonical

Open
#79 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

breaking-change enhancement
Dominant language
Go
Stars
27
Forks
24
Avg merge
12d 6h
Merged PRs (30d)
1

Description

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": [...]
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the protobuf definitions for WriteRequest, TupleKeys, and TupleKey, then inspect the Go code generated from them and the HTTP and gRPC request handling. The work is done when writes and deletes use repeated TupleKey values directly and both request formats consistently use the proposed shapes, with affected callers and tests updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.