2 ms·
The database really is an API, in that client code depends on it and its structure will be difficult to change once you go live, whether you want that to be tru
by drblast 8y ago
The database really is an API, in that client code depends on it and its structure will be difficult to change once you go live, whether you want that to be true or not. Writing the API before code that depends on it seems like an inherently good idea to me.
You can pretend like you don't need to figure these things out first and get away with it for a while, but at some point the lack of a solid foundation is going to bite you.
I think all devs should answer the question, "What if they don't want to use my UI or interface, or they want to automate something?" That's a good scenario to support for any client, including yourself.
- wwweston 8y agoI think it's really interesting that I find this insightful: > The database really is an API, in that client code depends on it and its structure will be difficult to change once you go live, whether you want that to be true or not. And then have a different conclusion than this: > Writing the API before code that depends on it seems like an inherently good idea to me. I'd guess it comes down to differences about the value of top-down and bottom-up approaches to systems. My experience is that top-down thinking usually is a better guide to creating the API you actually want to call -- writing the API calls you wish you had in the flow of the code, and then making them real. But then again, that's application-specific context, and may not lead one to answer the question "What if they don't want to use my UI or interface, or they want to automate something?"