I appreciate it.
IMHO our apps shouldn't depend on a third-party public API node. Each app should have its own API node.
I don't think we should charge the whole community for somebody's bot or script that may use one of these API nodes.
The public interfaces like hive.blog, peakd, and ecency should have their own API node. Which two of them, hive.blog and ecency, already have each an API node.
In the end, I'm not against it 100% but felt it's worth putting my opinion here.
Thank you for your comment and feedback :)
I do agree in terms of each app having its own API nodes for both stability and performance's sake. However, we have to consider the fact that it is not easy to maintain a global node network. Especially for apps. Currently, I believe all but one of the public nodes available are hosted in Europe. Setting up nodes in different continents and making them work together in an efficient manner is no easy feat (and is definitely not cheap).
Not to mention that it is important to give people more options to choose from. What happens if hive.blog API is down? What happens if ecency's API is down? Considering @blocktrades' website was hosted on OVH and the datacenter, literally, burnt down a couple of months ago... what if that was the DC API node was stored in.
If I write further, I'll probably go off-topic, but in summary, while apps can and should have their own nodes (not just social sites, all important apps should IMO, but it is important to note that not all apps are generating revenue or have DHF proposals to pay for global node infrastructure for itself) it is also important to offer third-party nodes for the sake of decentralization. A different node operator, a different server provider... a different continent altogether.
I agree on it too. That's the best for decentralization. Everything that's free, gets abused.
I think if dapps want an API node, they can also use some together.