Wiki.Quizz.vn

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== OpenFGA Store ======

A **Store** is the top-level container in OpenFGA. Think of it as one project or
one workspace. Everything for one authorization setup lives inside it, and
nothing leaks out to other stores.

===== Why stores exist =====

You need a boundary. Without one, all your rules and data would sit in a single
shared pile. Stores give you clean separation.

Each store is fully isolated. A Check inside store A can never see tuples that
live in store B. This lets you keep different apps, or different environments
(dev, staging, production), completely apart.

===== What is inside a store =====

A store holds three things.

^ Part ^ What it is ^
| **Authorization models** | The rules (''type'' and ''relation'' definitions). Versioned. |
| **Relationship tuples** | The data. Small facts like ''(account:123, assignee, role:manager)''. |
| **Assertions** | Saved tests: example questions with expected answers. |

==== Authorization models ====

The rules. A store can hold //many versions// of the model over time. Each
version gets its own model ID. When you change the rules, you write a new
version; the old one stays. Your tuples keep working, and you can point a Check
at a specific model version if you want.

==== Relationship tuples ====

The data. All the small facts like:

<code>
(account:123, assignee, role:manager)
</code>

This is usually the biggest part, sometimes millions of rows.

==== Assertions ====

Saved tests. You write example questions with expected answers, like "manager
should be allowed to approve → true". They let you check that your model still
behaves correctly after a change.

===== How you use a store =====

Every store has a unique **store ID** (a long string). This ID is the key to
everything.

  - **Create** a store once. OpenFGA gives you back its ID.
  - **Scope** every API call to that ID (write a model, add tuples, run a Check).
  - **Isolate** by design. One store's data never mixes with another's.

===== How many stores should you have =====

This is a design choice, not a fixed rule. Common patterns:

  * **One store per environment**: separate dev, staging, production. Safest start.
  * **One store per application**: give each unrelated app its own store.
  * **One store per tenant**: strong isolation, but more stores to manage. \\ Many teams instead keep all tenants in one store and separate them using object IDs (like ''organization:acme'' vs ''organization:globex'').

<note tip>
A good default: start with **one store per environment**, and only split further
when you have a real reason.
</note>

===== See also =====

  * [[https://openfga.dev|OpenFGA official site]]
  * [[https://openfga.dev/docs/getting-started/create-store|Create a store]]