"It is risky to release an app that depends on APIs that you don't control."

Yeah, dude, we also live in the real world.

Better to say: "Your app should handle cases where the third party API is partially or even totally down."

God, some people, they build a wall of rules around themselves and wonder why their skills don't improve.

Saying that it's risky doesn't mean that you should never take the risk.

I think it's a valid point. Deoending on how important uptime and quality of service of the product is, relying on a third-party API that is not of good quality might break the neck of that product.
Managing dependencies is an important part of software development.

Are the C library and kernel calls a third party API? Can you count special function registers as an API?

You can't eliminate other dependency when you don't make your own controllers but you can reduce the risk by using only old, well tested and proven APIs that are still in use today.

Using a third party API: No significant skill improvement.

Researching the topic and writing the functionality yourself: Significant skill improvement.

Most devs are just advanced users. They write scripts that use actual software written by someone else...

@Oktokolo how deep do you need to go so you're not just using software written by someone else? I don't think writing assembly is even deep enough, I guess you need to be a chip designer.

@electrineer You're not living 'till you are placing all the gates with tiny chopsticks and put it all together

@electrineer: Well, just writing glorified scripts actually is, what most customers are actually only willing to pay for...

But my point was about increasing skill - and you need to actually build functionality to practice the core skills of a coder - only chaining highest-level API/lib calls isn't really cutting it. Doesn't mean, you shouldn't use other people's stuff. But you definitely shouldn't _only_ be able to use other people's stuff. That is the (somewhat fuzzy) border between a coder and a code monkey - the latter _only_ chains other people's functionality together and is trivial to replace as there is an abundance of them.

Also, each library or API is a huge liability. Deep dependency trees are as toxic for software security as is the dogma of not using libs at all. When you can reasonably avoid an API or a lib with a few lines of code, it is generally better to do so.

@Oktokolo your vision made sense before we invented an OS. So you do you and spend 10 years developing hardware interactions for your web survey...

@Oktokolo ah your second commend makes a bit more sense.
Still disagree a lot. You should understand the problem and chose both your partner's and dependencies wisely. It makes no sense to write everything yourself not because of time spend writing but because of maintenance and effort. Sure I can make it work but a lot of things are already solved better and keep working better because there is a group maintaining it.
Having lot of dependencies does not mean they are deep.
I'd rather maintain and do knowledge transfer of a script that relies on a single cloud providers services than 2 million lines of code (that still runs on said cloud provider for reliability)

@hjk101 I disagree. Look at the mess with NPM and the security problems of it.

@happygimp0 That has nothing to do with what I said.
If anything is also used in the JS ecosystem as a complete failure it does not mean the whole concept is a failure.
For example with that logic "No language should ever come with time library build in, look at the JS Date mess".

Also I did say to both understand and pick dependencies wisely. In my example I used services not libraries. Never the less package managers and libs are a great concept that solve a lot of issues. Using it to bundle an entire browser and crapload of libs the size of an OS just to show a tray helper. Yeah can't endorse that.

@hjk101: 3rd-party services are like unfree closed source libraries - except you have absolutely no control over the update cycle and they can suddenly disappear.

@Oktokolo That is why with services you should consider them more as partners and evaluate them in that respect.

I agree fully with you although the disappearing any second is a bit dramatic. Perhaps I was lucky but 6 month notice period was the minimum and that was for a service that didn't get out of beta.

Anyway your partner should provide a lot of value like the classical example of sending mail. A service can manage delivery, bounces, replies, stats, selections, campaigns, design tools for marketing. A lib and infrastructure that provides this maintain will take a small dedicated team and still will likely not be as good as a Service that had spend years developing it's service.