Don't let table models become an API

As a software engineer, we would never make our database directly available to consumers.

Instead, we would always create an API.

We do this because we don’t want our table model to become the API, as doing so causes a number of problems:

• We directly expose our internal names and types, which may not match the expectations of the business user (i.e. what exactly is a user in this context?)
• The data may be too fine-grained and require a lot of transformation to meet the user requirements
• We restrict our ability to change our table model without breaking downstream applications

And yet, data teams often ingest data directly from the database, often without the software engineering team being aware.

Which is why we have each of those problems with upstream data.

That’s been known for a while, but it’s becoming a more important problem for the business as this data is now increasingly being used to power product features, either directly or through the use of AI, and it’s not ok for those product features to be slow to build and unstable in production.

Software teams solved this problem by using APIs.

Data contracts provide the API for data.