[ROARosen]

Just because you don't find any legitimate use case for this doesn't mean there is no use case. IMHO the more API coverage a platform can provide the better. Obvs only when it's possible to do so in a safe manner.

For instance I'm in the process of building a VScode and browser extension that would automatically star repo's of all npm packages and linked scripts used in your code (including dependencies). I think that's a basic gratitude thing for myself, and a tool some people might be interested in.

[wpietri]

> the more API coverage a platform can provide the better

This is a very common opinion of people who consume APIs, but people maintaining the APIs often feel differently. Every API endpoint is a promise, and it's also a constraint on future innovation. Firefox is a good example, in that their old API allowed extensions to "intimately intertwine" [1] themselves, which proved a huge barrier to improving the Firefox core.

[1] https://arstechnica.com/information-technology/2015/08/mozil...

[ROARosen]

>Every API endpoint is a promise, and it's also a constraint on future innovation.

I'm not referring to keeping any particular API endpoint alive. The problem you raise can be easily mitigated with a correctly built-out API versioning system and - more importantly - API deprecation policy.

I'm referring to just API coverage of platform features. In that sense maintaining API's can be viewed as not much different than maintaining the actual platform features themselves. Obviously the more feature you provide the more maintenance/resources will be required. That goes for both API's and the features themselves.

[wpietri]

Oh? If it's that easy, could you explain how you would have applied that in the Firefox case and avoided the massive problems they experienced?

Because in my view their problem wasn't about API versioning. They came out with a new version and deprecated the old, after all. It was that they provided way too much coverage early on.

[ROARosen]

I don't get your point. There will obviously be cased where API's are not needed or too complicated to maintain, which was presumably the case with Firefox, which BTW is a locally installed platform. I don't see how this affect the general discussion regarding (mostly) web platforms - which usually run on a client-server model anyway - maximizing their API footprint to expose the most functionality possible via their API.

Just because you or anyone working there doesn't see a useful use case for using that functionality over the API doesn't mean there won't be someone who will come up with something useful based on that in the future.

[wpietri]

My point is very simple. You said "the more API coverage a platform can provide the better". I'm saying that's not true because it can create large long-term costs that outweigh the benefits. I even gave an example. I get why you as an API consumer want maximum surface area. But API producers often feel differently, and they have good reason to. I think the better general strategy for API producers is to open up gradually based on actual need discovered via dialog with community.

[Karellen]

Service providers provide APIs.

Devs build apps that use APIs.

Users install apps that use APIs.

Users build their workflows around apps that use APIs.

Sometimes devs get bored/burn out/get a family/die/get a promotion, and stop building new features for apps. Sometimes, if users are lucky, they'll stay on top of security issues. But maybe, users install an app once and never update it even if it is getting updates. Which is risky, but if it works for them, whatever.

Service provider kills API endpoint.

App breaks.

User's workflow breaks. Worked yesterday, does not work today. :-(

Maybe, if the user is lucky, they connect with other users of the app, or users of other apps that are similarly affected, and they figure out workarounds, or someone creates a fork of the app(s) to use your new equivalent endpoint (if you even created one!) and, eventually, after much wailing and gnashing of teeth, they pick up the pieces of their workflow which you just broke and cobble together a new one.

But you caused them hours and hours of pain.

See also https://xkcd.com/1172/

[mh-]

Having seen some pretty deep npm trees, I worry what you're building could end up (accidentally) doing hundreds or thousands of stars.

I'd be careful to not make it recursive, at least - only look at direct dependencies.

[askiiart]

Sounds cool, except that people will get banned. I'd recommend making a menu where people can click on individual dependencies to star, or have a button to star all (but with a very clear warning about the possibilty if getting banned).

[ROARosen]

Great idea! will keep in mind.

[pydry]

Please dont. Your extension will probably get more people banned when they star 1200 repos.

[AdrianB1]

>> the more API coverage a platform can provide the better

The more attack surface, the better?