3 ms·
the database schema is an API like everything else, and you can solve API evolution problems the same way as you would with a web API, using eg. views, stored p
by chousuke 5y ago
the database schema is an API like everything else, and you can solve API evolution problems the same way as you would with a web API, using eg. views, stored procedures and versioning.
There's no reason not to expose parts of your database schema directly to users as long as you treat it like you would any other API you provide.
- LukeEF 5y agothis is a really interesting way to think about it and something that I've given a fair amount of thought to as we embark on a data mesh journey - how does a domain team serve up a schema like an API, how does it evolve, and how do we think about versions.
- onefuncman 5y agothat's what a Schema Registry is for... protobuf is a little more polished around managing forwards and backwards compatibility than avro but they both work.
- chousuke 5y agoI find that there are very few things related to programming that don't constitute an interface in some way, so it feels natural to me to think about everything in terms of the interface it presents to users, both explicitly in what you can express via whatever language you're using, and implicitly via conditions that can't be enforced but are required for correctness. And when you have an interface, you really ought to put some thought into its design regardless of how "private" it is. An API is an interface used by a program in some way, and any user-exposed database objects definitely qualify under that definition.