Custom APIs

[bedeho]

Background

Sometimes we want some API feature which either is not present, or is too slow, and we have to either make complex changes to Hydra to accomodate some edge case - which typically requires some long delay, or we have to start doing hacky workarounds.

Proposal

Implement something like this https://docs.subsquid.io/reference/api-extensions.

But this is only worth doing if its super easy.

[dmtrjsg]

Won't get to this until we migrate to subsquid

[bedeho]

Why tho? I think this is pretty much child's play, and has big impact, am I wrong about either premise?

[dmtrjsg]

@kdembler @zeeshanakram3 @thesan pls feel free to chime in.

[zeeshanakram3]

Certainly, custom resolvers(APIs) would save us from hacky solutions, but now we have workarounds for things where we felt the need for something not generated by templated hydra resolvers. So for new mappings, if we feel the need for this, we may use it.

Also, Subsquid has builtin support for adding custom resolvers, but the steps described in https://docs.subsquid.io/query-squid/api-extensions do not seem to apply to the current version of Hydra; however, with some tweaks, we can achieve that, maybe write a script to serve the unified view of custom + generated query resolvers.