3 ms·
> You haven't really saved yourself from the hassle of designing and maintaining backward compatibility for the API. Another way to look at it is that changing
by dane-pgp 6y ago
> You haven't really saved yourself from the hassle of designing and maintaining backward compatibility for the API.
Another way to look at it is that changing the database schema is already a problem for the API which has to talk to it, so you're not really saving yourself any work by putting an extra layer between the frontend and the database.
In fact, if anything, you're doubling the amount of work, because there are now two interfaces (DB to API, and API to frontend) whose backwards compatibility you have to worry about.
- throwawaygh 6y agoYes. The decision calculus here really boils down to how many clients the API has and how much you care about those clients. If you have 100 other teams each with 5+ developers consuming your API -- or especially if your API is a product -- then keeping the API to frontend interface relatively stable with rare breaking changes is much more valuable than saving yourself even a major time commitment on DB to API work. On the other hand, if you have relatively few clients -- or if the clients are "lower status"/"cheaper" teams -- saving time on the DB to API work a the expense of client teams might make sense.