Why Polkadot-API?

[josep]

Thanks for the reply, @leonardocustodio. Let me address your points directly and keep this grounded in facts.

@leonardocustodio

the first time I tried to use PAPI, I had issues with it. You can check for yourself, and I basically got ignored

I don’t think that’s accurate. We responded on GitHub immediately, and I also reached out on Matrix and later in person in Lucerne to share a solution. You stopped replying, and a call invitation went unanswered. Happy to continue that conversation any time, publicly on the issue or live, your choice.

@leonardocustodio

I was told I was doing it wrong yet no alternatives were given to me.

This is categorically false. No one told you that you were “doing it wrong.” On the contrary: we explicitly acknowledged the need you raised and prioritized typed-codecs, which shipped a few weeks later despite a heavy workload. (As a side note, Dedot doesn’t have this feature.)

@leonardocustodio

I also see another person had a similar question and this is part of the answer given to him:

As you can imagine, this APl is meant for Uls and not for indexers

This is out of context. I was referring to a specific API: watchEntries, which is not intended for indexing very large storage maps like System.Account. (As a side note, Dedot doesn’t offer this API).

PAPI can be used for indexers. For example, https://xcscan.io/ uses PAPI for their indexer and saw substantial performance improvements after migrating. We’re building an indexer ourselves and we know that PAPI is a great choice for indexers. One reason being its ability to recover cleanly from network outages and reconnections (another area where Dedot currently struggles, btw).

@leonardocustodio

I’m pretty sure that it is not mentioned in the documentation that PAPI is meant for use only in products which the PAPI team thinks it makes sense.

Yet, it seems its author are always claiming it is the best one to choose.

That is a very weak strawman argument. We advocate interoperable interfaces and clean boundaries. That’s not “use PAPI or else”; it’s “use standards so tools can be swapped without pain.” Compete on implementation, align on interfaces.

@leonardocustodio

So @josep let me tell you something that might be hard, if I can’t get one product done because of your API, I will choose the one that can get the job to be done every single time.

In this case, the blocker you hit was a limitation of the modern JSON-RPC spec, the one maintained by Parity (the company that you work at, right?), not “my API.” We acknowledged it, proposed a workaround, and we’re contributing upstream to improve the spec. Since you graduated from PBA, you also know why deprecating legacy RPCs matters. It’d be great to have your help shaping the modern spec so these gaps close faster. Also: one limitation shouldn’t negate the many operational advantages of the modern spec.

@leonardocustodio

Also nice impact phrase “pick standards” you should also put next to it “my standards” so it sounds a bit more like what you are doing.

They aren’t “my standards.” The minimal JSON-RPC provider interface PAPI uses was largely articulated by Pierre Krieger for substrate-connect, and further simplified precisely because the modern spec enables it, see this reminder we got back then. The signing interface work is similarly being discussed in the open with multiple stakeholders (e.g. here). These are ecosystem standards by design, decoupled from PAPI internals and meant to be adopted broadly.

@leonardocustodio

Finally, l’ve run the stupidest benchmark I could think of, here:

Could you share the code, please? From your numbers it looks roughly identical on that micro-case. It’d be useful to see results over a longer run, where memory behavior and reconnection handling matter. Also remember: the benchmark we used in the post wasn’t “crafted by us”, it was authored by Dedot; we simply ported it to PAPI.