[Experiment]: A new Indexing protocol solution for Rollups

📄 Context

Subgraph was the first (allegedly) good solution in the market as an indexing protocol. Still, it lacks flexibility on the graphQL API that force us to create summary entities here and there and more complex cases with pagination become constrained, if not impossible. Furthermore, we can't extend the graphQL API with custom resolvers which would be a killer feature (making that experiment unnecessary); on top of that is the language chosen, i.e. AssemblyScript, which is confusing since it uses the extension .ts, causing all sorts of pitfalls along the way until you become a scarred warrior 🥷. Besides that, the way we have our Subgraph set is working, but I want to look at other indexing protocol solutions available like subsquid or satsuma

✔️ Solution

For this experiment, I will pick the Subsquid. I'll add the pros and cons below and focus on my perceived benefits from the DX perspective. The deployment of the squid in the Aquarium service has its learning curve and details (e.g. Premium users vs Free users).

Pro

GraphQL API can be extended with a custom resolver, including mutation.
GraphQL subscriptions available.
Write handlers in plain javascript and/or typescript.
Can call external API for data since it is the usual node.js process.
Self-hosting is an option.
Offers a hosting service called Aquarium
- Alias to production endpoint with promotion between squid without downtime*
Cons
New programming model called batch-based, so there is a learning curve here.
No Goerli archive node offered, only Sepolia. PS: not really a strong con, but I want to point that out.

📈 Subtasks

[x] Create the Squid backend for Rollups into the Monorepo.
[x] Map the contracts we are indexing.
[x] Extend the graphQL API for performance
[x] Could we use graphQL generators and easily integrate with the hooks we already have? yes/no
[x] Space for more tasks/checks as fit [optional]

cartesi / explorer