Define a GraphQL package boundary and metadata-sharing strategy for Tango

[danceroutine]

Summary

Tango already has strong model, serializer, resource, and OpenAPI metadata. A future GraphQL surface should not ignore that work, but it also should not blindly mirror the REST-style resource layer.

The key missing step is an explicit package boundary and metadata-sharing strategy.

Current codebase context

• Tango currently has resource-layer and OpenAPI packages, but no GraphQL package at all.
• The roadmap explicitly frames the open design question as how much model and serializer metadata should be shared between REST-style resources and a future GraphQL surface.
• Any GraphQL work will have to decide how it relates to serializers, viewsets/resources, query planning, and N+1 avoidance.

Problem

Without an explicit architectural decision first, GraphQL implementation work risks either:

• duplicating metadata that Tango already owns elsewhere
• over-coupling GraphQL to REST-shaped abstractions that should remain independent

That makes the roadmap item too ambiguous for contributors to tackle productively.

Proposed implementation plan

1. Write an ADR for the GraphQL boundary.
   • Decide the package shape (for example @danceroutine/tango-graphql) and the layers it is allowed to depend on.
2. Define metadata-sharing rules.
   • Specify which model/serializer/resource contracts are reused directly, adapted, or intentionally not shared.
3. Define an MVP scope.
   • Choose a first slice such as schema generation only, read-only query fields, or a small mutation story.
4. Identify runtime concerns early.
   • Cover resolver execution, relation loading/data-loader strategy, and error mapping before implementation begins.

Acceptance criteria

• Tango has an explicit ADR for the GraphQL package boundary and metadata-sharing model.
• The first implementation milestone is scoped tightly enough to be actionable.
• The design calls out how GraphQL will interact with serializers/resources/query loading rather than leaving that implicit.
• Contributor docs point future implementation work at the agreed boundary.