3 ms·
You can, but I'd argue if your API schema is just 1-to-1 views for the underlying tables, you're not getting much value from this approach.
by claytonjy 3y ago
You can, but I'd argue if your API schema is just 1-to-1 views for the underlying tables, you're not getting much value from this approach.
- spott 3y agoUntil you change the underlying tables, or the api schema. At which point you don’t need to change the other.
- claytonjy 3y agoIf your API view is a direct mapping of an underlying table (e.g. "SELECT *"), and you make a breaking change to that table, the view will also change and your application will break. What I've done instead is change the underlying table as needed, and ensure the view interface stays the same, by changing the view definition. This lets you refactor the low-level schema without breaking clients, and this migration can be done in a single transaction.
- packetbeats 3y agoI was thinking of it as the starting point, then you evolve from there. Tbh, views are a bit of a leaky abstraction (for example when it comes to constraints) so adopting them gradually seems like a good idea.