EgeAytin

It’s a very interesting idea. How does it perform compared to a regular data warehouse?

In a standard relational based databases, the suggested place to write relationships to Permify is sending the write request in database transaction of the client action: such as assigning the user as owner.

If the transaction fails, you should delete the malformed relation tuple from Permify to maintain consistency.

Here's an example of how this might look in code:

```

func CreateDocuments(db *gorm.DB) error {

  tx := db.Begin()
  defer func() {
    if r := recover(); r != nil {
      tx.Rollback()
      // if transaction fails, then delete malformed relation tuple
      permify.DeleteData(...)
    }
  }()

  if err := tx.Error; err != nil {
    return err
  }

  if err := tx.Create(docs).Error; err != nil {
     tx.Rollback()
     // if transaction fails, then delete malformed relation tuple
     permify.DeleteData(...)
     return err
  }

  // if transaction successful, write relation tuple to Permify
  permify.WriteData(...)

  return tx.Commit().Error

}

```

Although this is an anti-pattern, this approach ensures that if the transaction in the application database fails and is rolled back, the corresponding data in Permify is also deleted, preventing inconsistencies.

Firstly, while IAMs often offer some level of authorization capabilities, they are not as flexible or fine-grained as dedicated authorization systems like Permify.

Therefore, customizing complex permission logic (such as hierarchical relationships, user group, etc.) can be challenging in IAMs. As an example, Keycloak's Authorization Service supports RBAC and ABAC it does not support ReBAC.

Another point is that authorization as a service solutions are focused entirely on authorization. This means they provide not only fine-grained permissions but also tooling and functionality to ease testing and observability of the authorization system.

Also Permify leveraging Google’s Zanzibar scalable data model and unified ACL (Access Control List) approach, enables the creation of a centralized authorization service capable of handling high volumes of data and access checks across your microservices stack.

Still, it's worth mentioning that if you have a basic authorization system or need, it makes total sense to use the solutions you mentioned for handling the authorization part as well. However, if you want to scale your authorization, especially in a microservices environment, I would suggest trying one of the authz providers instead.

While we don’t have exact solution or workflow for handling this case, I can suggest an approach that might help.

Assuming that you apply pagination to the search results, you can send the results to Permify one by one, as you'll only be displaying a limited number to the user. Permify is designed to handle millions of requests per second, so this approach won't cause any issues for your specific case.

While this solves the issue, sending multiple checks at once could create a problem as the number of items on the page increases, though it shouldn't be much of a problem even 500 items.

Authorization libraries can be useful but often fall short in key areas. They typically lack fine-grained access control, limiting their ability to handle complex permissions. Casbin does provide RBAC and ABAC but as far as I know they don't support ReBAC.

Libraries was designed to operate directly on an application’s existing data structures without imposing a standardized model for how that data should be organized.

Direct interaction with diverse data structures can lead to inefficiencies and performance bottlenecks. Without a standardized model, the library might not optimize data access and manipulation as effectively as it could with a uniform data structure.

Additionally, they struggle in microservices architectures, creating challenges in maintaining consistent security policies across services. In a microservices architecture, each service might require access to the authorization library, but replicating this library across services can lead to maintenance, synchronization, and consistency challenges.