Support For Data Client Type Organization

by ADMIN 42 views

Describe the Feature You'd Like to Request

When creating custom mutations and queries, they're often related to a specific model. However, the client schema type always groups them in the client.queries and client.mutations objects. This can lead to a cluttered and disorganized schema, making it difficult for frontend engineers to navigate and understand the relationships between different data resources. Additionally, there is no way to group models and queries that have similar concerns, which can further exacerbate the issue.

Support for various ways to organize the generated schema would be incredibly helpful for supporting frontend engineers, keeping the backend codebase and schema clean, and just generally improving the overall development experience (DX). By providing a more structured and organized way to group data resources, developers can focus on building features and solving problems, rather than navigating a complex and confusing schema.

Describe the Solution You'd Like

I'd like the ability to group data resources into namespaces, and group custom queries/mutations within a model. This would allow developers to create a more hierarchical and organized structure for their data resources, making it easier to understand and navigate the schema.

For example, let's say you have a model and a handful of queries relating to user management. You could create a user namespace accessed in the client by client.user. Then, say you have a custom mutation called updateUserPermissions that could be accessed by client.user.models.userInfo.updateUserPermissions instead of the flat client.mutations.updateUserPermissions.

This would provide a more intuitive and organized way to access and interact with data resources, making it easier for developers to build features and solve problems.

Describe Alternatives You've Considered

To keep our API organized, my team has so far been prefixing our resources. For example, our backend has a few isolated areas of concern (essentially separate sub-apps) and we've been adding the sub-app name to the start of each model and custom query/mutation. While this approach has helped to some extent, it's not a perfect solution and can still lead to a cluttered and disorganized schema.

Additional Context

This feature request was discussed briefly during the office hours on 3/13. The discussion highlighted the need for a more organized and structured way to group data resources, and the potential benefits of implementing a namespace-based system.

Is This Something That You'd Be Interested in Working On?

  • I may be able to implement this feature request

Would This Feature Include a Breaking Change?

  • This feature might incur a breaking change

Benefits of Implementing a Namespace-Based System

Implementing a namespace-based system would provide several benefits, including:

  • Improved organization and structure: By grouping data resources into namespaces, developers can create a more hierarchical and organized structure for their data resources, making it easier to understand and navigate the schema.
  • Increased flexibility: A namespace-based system would allow developers to create custom namespaces and group data resources in a way that makes sense for their specific use case.
  • Better scalability: As the schema grows and becomes more complex, a namespace-based system would provide a more scalable and maintainable solution.
  • Improved developer experience: By providing a more intuitive and organized way to access and interact with data resources, developers can focus on building features and solving problems, rather than navigating a complex and confusing schema.

Implementation Details

To implement a namespace-based system, the following changes would be required:

  • Add support for namespaces: The client schema type would need to be modified to support namespaces, allowing developers to create custom namespaces and group data resources within them.
  • Update the client API: The client API would need to be updated to reflect the new namespace-based system, allowing developers to access and interact with data resources in a more intuitive and organized way.
  • Implement namespace-based grouping: The system would need to be modified to group data resources within namespaces, allowing developers to create a more hierarchical and organized structure for their data resources.

Conclusion

Q: What is the current state of data client type organization?

A: Currently, the client schema type groups custom mutations and queries in the client.queries and client.mutations objects. This can lead to a cluttered and disorganized schema, making it difficult for frontend engineers to navigate and understand the relationships between different data resources.

Q: Why is a namespace-based system needed?

A: A namespace-based system is needed to provide a more organized and structured way to group data resources. This would allow developers to create a more hierarchical and organized structure for their data resources, making it easier to understand and navigate the schema.

Q: How would a namespace-based system work?

A: A namespace-based system would allow developers to create custom namespaces and group data resources within them. For example, a user namespace could be created and accessed in the client by client.user. Custom queries and mutations could then be grouped within this namespace, making it easier to access and interact with data resources.

Q: What are the benefits of a namespace-based system?

A: The benefits of a namespace-based system include:

  • Improved organization and structure: By grouping data resources into namespaces, developers can create a more hierarchical and organized structure for their data resources, making it easier to understand and navigate the schema.
  • Increased flexibility: A namespace-based system would allow developers to create custom namespaces and group data resources in a way that makes sense for their specific use case.
  • Better scalability: As the schema grows and becomes more complex, a namespace-based system would provide a more scalable and maintainable solution.
  • Improved developer experience: By providing a more intuitive and organized way to access and interact with data resources, developers can focus on building features and solving problems, rather than navigating a complex and confusing schema.

Q: Would a namespace-based system require a breaking change?

A: Yes, a namespace-based system would likely require a breaking change. The client API would need to be updated to reflect the new namespace-based system, and developers would need to adapt their code to use the new namespace-based system.

Q: How would a namespace-based system be implemented?

A: To implement a namespace-based system, the following changes would be required:

  • Add support for namespaces: The client schema type would need to be modified to support namespaces, allowing developers to create custom namespaces and group data resources within them.
  • Update the client API: The client API would need to be updated to reflect the new namespace-based system, allowing developers to access and interact with data resources in a more intuitive and organized way.
  • Implement namespace-based grouping: The system would need to be modified to group data resources within namespaces, allowing developers to create a more hierarchical and organized structure for their data resources.

Q: What are the next steps for implementing a namespace-based system?

A: The next steps for implementing a namespace-based system would be to:

  • Gather feedback and input: Gather feedback and input from developers and stakeholders to ensure that the namespace-based system meets their needs and requirements.
  • Design and implement the namespace-based system: Design and implement the namespace-based system, including the necessary changes to the client schema type and client API.
  • Test and iterate: Test and iterate on the namespace-based system to ensure that it is stable and meets the needs of developers and stakeholders.

Q: Who would be responsible for implementing a namespace-based system?

A: The implementation of a namespace-based system would likely be a collaborative effort between the development team and stakeholders. The development team would be responsible for designing and implementing the namespace-based system, while stakeholders would provide input and feedback to ensure that the system meets their needs and requirements.