In small biscuit deployments (a couple of services, in a single organization), you have full control on which rules and facts are defined and have meaning. On bigger deployments (across multiple organizations, or if you want to design a reusable library that can be used by multiple services), you will need to be more careful about avoiding name collisions.
While there are no well-defined patterns that have emerged yet,
a good practice is to prefix fact names with the organization name,
separated by a colon (
:). So for instance:
// can collide with other facts user("1234");
// makes it clear that the user is tied to a specific organization wayne_industries:user("1234");
Using namespaced fact names will make tokens a bit bigger for two reasons:
- well, they're longer;
- names like
userthat are part of the default symbol table are only represented by an index in the wire format.
The size increase will be mitigated by string interning (you only pay the extra cost once).
Another thing to note is that namespacing is not a security feature. It prevents accidental name collisions, but is not a proper way to separate facts based on their origin. Third party blocks provide such a mechanism. Namespacing can be used in conjuction, to make things easier to read and understand.