Provide a working example of the indexer stack with v2 processors, using docker compose

[ganymedio]

Infra team will be working on the new IaC for the indexer soon. They mentioned that from the engineering side, a working example that uses docker compose would be enough.

@larryl3u has articulated a couple options for handling the transaction stream:

- Option 1:
Fullnode(StatefulSet): easy to deploy, performance may degrade when load is high
No ability to scale up infinitely

- Option 2: 
Fullnode(StatefulSet) -> grpc manager + file store -> data service(service) 
Complicated 
Easy to scale up

I've set up Option 2 already and will orchestrate with docker-compose... I think @larryl3u has made some progress on Option 1 so perhaps it would make sense for him to continue with that?

We are leaning toward Option 1 for the sake of easier deployment and probably lower cost to run... given that most if not all production dApps use paid indexer services run by third party ecosystem partners, it seems like optimizing for ease of implementation for our hosted indexer may be best.

However, it may makes sense to have examples with docker-compose for both options in case there is some reason to deploy Option 2 at any point.

[larryl3u]

let me finish the migration POC and we can see how it'll be fit into your docker compose.

[ganymedio]

let me finish the migration POC and we can see how it'll be fit into your docker compose.

@larryl3u @musitdev I was thinking of opening a discussion to confirm, but I guess this issue is fine as a place to discuss: we've decided we want to go with Option 1 above, right?

• Option 1:
  Fullnode(StatefulSet): easy to deploy, performance may degrade when load is high
  No ability to scale up infinitely

I was working on docker compose for Option 2 yesterday and ran into several unexpected issues with the docker compose... thinking I should switch to trying to do it with Option 1 instead, if we're deciding to go with that simplified stack. Given that we have several ecosystem partners running paid nodes, I'm in favor of Option 1.

[musitdev]

I think it's ok to work on Option 1 or 2, it's not very different. The choice will be made with SRE and depending on the needs. But first, we must define the main purpose: is it an indexer for our own application, or do we want to provide a reliable public indexer service?

[ganymedio]

I think it's ok to work on Option 1 or 2, it's not very different. The choice will be made with SRE and depending on the needs. But first, we must define the main purpose: is it an indexer for our own application, or do we want to provide a reliable public indexer service?

From what I understand it's just for our own application and hobby users, not for a reliable public indexer service... @0xmovses or @sausagee to clarify / confirm 🙏

[0xmovses]

Go with

Fullnode(StatefulSet): easy to deploy, performance may degrade when load is high
No ability to scale up infinitely

Lesser lift. We wont hit scale at early stages after Migration. If we see Indexer is slow to query, we can then introduce the grpc manager and other services.

[0xmovses]

cc @larryl3u