Projects
Introduction
A project in Hasura DDN is the foundation for building and managing your API. It contains a structured collection of metadata files that define the behavior, relationships, and permissions for your API. These metadata files are organized into subgraphs, each representing a distinct data domain.
Projects are designed to support both local development and cloud deployment. During development, you work with a local
version of your project, which is linked to a cloud project through a
context file. This linkage enables seamless
development, testing, and deployment workflows. You can also define multiple contexts (e.g., staging) to manage
different environments, with unique configurations for environment variables and cloud resources.
Data domains
A data domain in Hasura DDN represents a distinct area of responsibility or focus within your project, typically aligned with a specific team or business function. These domains are managed as subgraphs, which are collections of metadata files that describe the relationships, permissions, and structure for the data within that domain.
Organizing your project into subgraphs provides several benefits:
- Team Ownership: Each team can focus on their own data domain without interfering with others, making collaboration simpler and reducing bottlenecks.
- Clear Boundaries: Subgraphs establish clear boundaries between domains, making it easier to define and enforce data access permissions and relationships.
- Scalability: By breaking your project into manageable pieces, you can scale your API incrementally as your organization and data requirements grow.
- Flexibility: Subgraphs can be independently updated and extended, allowing you to adapt your project to changing needs without disrupting the overall API.
This structure ensures that your project remains organized, collaborative, and adaptable, enabling you to build and maintain robust APIs efficiently.
Hasura DDN also supports multi-repository setups, giving teams greater autonomy in their development process. With this setup:
- Each team can maintain their subgraph in a separate repository while still contributing to the shared supergraph.
- Teams can develop, test, and deploy their subgraphs independently, enabling faster iteration and minimizing dependencies on other teams.
- The supergraph integrates these subgraphs into a single API, ensuring that the overall API remains consistent and cohesive.
This approach is ideal for large organizations where multiple teams work on distinct data domains but need to collaborate through a unified API. For more information, check out this section of the docs.
