Platform evolution best practices

Recommended: Use FIDL types and protocols to define interfaces between any two things that may evolve separately. Leverage the FIDL rubric where applicable.

Not recommended: Avoid languages other than FIDL to define interfaces where independent evolution matters. These include: plain text, JSON, and protocol buffers.

When reviewing alternatives, ask yourself what affordances they have for evolution.

  • Is there a schema for the data?
  • Can the schema change over time, while providing backward/forward compatibility? How?
  • What changes to the schema are API/ABI preserving/breaking? How would you know before committing a breaking change?
  • Is the wire format stable?

Recommended: Be careful when designing platform APIs and ABIs for use outside the platform. Design for evolution, find ways to enforce that your clients use the intended interfaces, and don’t offer ways to circumvent the interface.

Not recommended: Avoid exposing your clients to your implementation details that are not contractual. Common mistakes include exposing broadly-scoped capabilities or namespaces, and leaking implementation details via URLs, component monikers, and diagnostics selectors.