I wanted to open a discussion around what we accept as “schema-driven” in Meshery.
This came up while reviewing workspace view in mesheryctl:
The PR exposes a boundary that I think we should define clearly:
When is local mapping still schema-driven, and when does it become drift? Or should local mapping be avoided altogether when a generated schema response type already exists?
A local mapping layer is not automatically wrong. A consumer may need to reshape data for presentation, compatibility, or a stable user-facing output.
But if the API already returns a generated schema response type, and the consumer maps it into another local type, we should be clear about what that means.
My current opinion is that consumers should use generated schema response types directly by default.
Local mapping should be the exception, not the default.
If local mapping is used, it should have an explicit reason, for example:
- preserving an existing user-facing output contract
- hiding fields that are not useful for that consumer
- formatting data for display
- supporting backward compatibility
But the mapping should not silently change the schema contract.
One caveat with local mapping is that every schema change also has to be reflected in the mapping layer. If that is missed, the consumer can drift from the schema and create extra maintenance burden.
So the boundary I want to clarify is:
Should consumers use generated schema response types directly by default, and only introduce local mapping when there is a documented consumer-specific reason?
