feat(c/v3-engine) add possibility for namespacing when adding multiple data sources. Add possibility for permissions on namespaces and prefixes.

[Relaxe111]

Feature Request for Hasura v3: Namespacing for Multiple Data Sources
Current Behavior (Hasura v2)
In Hasura v2, when multiple databases are added as data sources, a namespace can be defined for each database. This enables GraphQL queries to group all tables and models from a database under a single, hierarchical namespace. Example:

query {
  customer1 {  # Namespace for Database 1
    tableA
    tableB
  }
  customer2 {  # Namespace for Database 2
    tableA
    tableB
  }
  sharedLogic {  # Namespace for shared logic
    ...
  }
}

Limitation in Hasura v3
In Hasura v3, the namespacing feature has been replaced with prefixes at the root level. While prefixes serve a similar purpose, they do not provide the hierarchical structure or flexibility that namespaces offered. Instead of:

query {
  customer1 {
    tableA
  }
}

You get:

query {
  customer1_tableA
}

This flat structure can be harder to manage and less intuitive, especially when working with a large number of data sources that share the same schema.

Proposed Feature: Reintroduce Namespaces for Data Sources in Hasura v3

1. Namespace Support
Allow users to define a namespace for each data source. All tables and models from the data source would be grouped under the namespace in the GraphQL schema.

Example configuration in metadata.yaml:

databases:
  - name: customer1_db
    namespace: customer1
  - name: customer2_db
    namespace: customer2

Resulting GraphQL structure:

query {
  customer1 {
    tableA
    tableB
  }
  customer2 {
    tableA
    tableB
  }
}

2. Namespace-Specific Permissions
To enhance the security and usability of namespaces, introduce namespace-level permissions that can restrict access to certain namespaces based on headers or JWT claims.

Example Permission Definition
In the metadata.yaml file, permissions could be defined for namespaces similarly to table-level permissions. For instance:

namespaces:
  - name: customer1
    permissions:
      - role: user
        condition:
          headers:
            X-Hasura-Allowed-Namespace: customer1
      - role: admin
        condition:
          headers:
            X-Hasura-Allowed-Namespaces:
              - customer1
              - customer2
              - sharedLogic
  - name: sharedLogic
    permissions:
      - role: user
        condition:
          headers:
            X-Hasura-Allowed-Namespace: sharedLogic

Behavior in Queries
If a request contains the header X-Hasura-Allowed-Namespace: customer1, the user would only be able to query the customer1 namespace:

graphql

query {
  customer1 {
    tableA
  }
}

Any attempt to query other namespaces (e.g., customer2) would be denied.

Wildcard or Multi-Namespace Support
If the header contains multiple allowed namespaces (e.g., X-Hasura-Allowed-Namespaces: customer1,customer2), users can query any of the specified namespaces.

query {
  customer1 {
    tableA
  }
  customer2 {
    tableB
  }
}

3. Optional Namespace Filtering Based on Dynamic Conditions
Enhance flexibility by allowing permissions to reference dynamic conditions like JWT claims or external data sources. For example:

JWT Claim-Based Filtering
Namespace access could be determined by a claim in the JWT token, such as allowed_namespaces.

namespaces/prefixes:
  - name: customer1
    permissions:
      - role: user
        condition:
          jwt_claims:
            allowed_namespaces:
              contains: customer1

Header-Based Filtering

namespaces/prefixes:
  - name: customer1
    permissions:
      - role: user
        condition:
          headers:
            X-Hasura-Allowed-Namespaces:
              contains: customer1

Benefits of This Feature
Improved Organization
Namespaces keep the GraphQL schema structured, making it easier to manage large projects with multiple data sources.

Enhanced Security
Namespace-level permissions allow granular control over access, ensuring that users or roles can only access the data sources they are authorized for.

Compatibility with Multi-Tenant Systems
This feature is especially useful for multi-tenant applications where each tenant has its own database but a shared schema.

Backward Compatibility
By reintroducing namespaces, developers familiar with Hasura v2 can seamlessly migrate to v3 without losing the benefits of hierarchical grouping.

Scalability
Supports large-scale applications with dozens or hundreds of customers, databases, or shared logic layers.

[robertjdominguez]

Thanks for sharing this detailed and thoughtful feature request @Relaxe111 — it’s clear you’ve put a lot of effort into outlining the current challenges, proposed solutions, and potential benefits of reintroducing namespaces in Hasura DDN.

I can see how this would help with managing multi-source projects, improving schema organization, and enhancing permissions for multi-tenant systems. I’ve passed your feedback along to the product and engineering teams for review, and while I can’t promise immediate changes, it’s precisely this kind of input that helps shape our roadmap. Someone will be in touch soon. Thanks again for contributing!