|
|
|
|
|
|
by klabb3
1202 days ago
|
|
|
> During a YC meetup I spoke with a fellow founder that told me how hard it was to pick the right external APIs to use within your own projects. I realized that most of what we build relies on public APIs from external vendors I have a habit of sleeping under rocks but why do people do this? It seems incredibly brittle and strictly worse than leftpad-esque dependency hell – you can’t freeze or fork an API. I can understand that for payments, maps or even email sending it’s more convenient, but that’s at least a bounded issue. Are the apps we are building today gonna work in 3 years without meticulous maintenance? Are we doomed to suffer flaky experiences from compound latencies and rate limiting? And what’s the point of your 5 nines if you rely on third parties anyway? |
|
|
We're implementing a new (cloud) platform that's pretty central to our primary business. Some sub-projects have already spun off, before we had even decided how to set up and maintain the platform, because I said to meet the timeline we need to focus on more broad, general integrations first.
The decision was, instead, to bring in additional developers whom several months later we're still helping learn the APIs and troubleshoot problems (amidst the rest of our integration tasks).
Meanwhile a few weeks ago, I finally got the go-ahead and a DBA's time to do the integration I wanted. We've got a live database of 90-some tables dumped from the platform, including everything these projects are fetching (but with a greater delay between updates), accessible to the entire org. Reporting teams and business analyst are already writing queries to drive the services they need, freeing up our developers to work on other tasks.
A good API can provide very rapid, very specialized development; which is great when that development _is_ your business and so you're paying developers to keep up with it, or it's not so important that is kept up on (personal projects, prototypes, and temporary services). And a well designed and managed API shouldn't change _that_ much _that_ frequently.
But ignoring that an external API is always something you don't control and needs to be maintained is a costly mistake I've seen my org fall into over and over again.