Review Alchemy Usage

[lightwalker-eth]

We're soon to hit the configured budget cap on our Alchemy account. I can raise this cap if needed, but before doing that: Appreciate if everyone could reply with their thoughts on our Alchemy usage and anything you recommend for streamlining our RPC needs.

We're currently on track to spend about $1,200 in Jan on Alchemy RPC calls. Not all of this is from our development of ENSNode. Another key contributor has been the GraphNode instance we're running. Related task here: #63

It looks like we stopped making any use of drpc. Did you guys find Alchemy to perform better?

We should give priority to our own efficiency as devs over efficiency of RPC usage, but appreciate advice and suggestions 👍

[tk-o]

Alchemy has been performing better, but since we now have the RPC cache built for all supported ENSNode plugins, we can switch to drpc keys and see how its cost profile looks like.

[tk-o]

@lightwalker-eth I forgot to mention that I've been running another instance of ENSNode on my cloud server, and it's been using Alchemy keys. It has now also the RPC cache built fully, so it should not require a heavy load of RPC calls.

[lightwalker-eth]

@BanaSeba Hey I think the key next step here is to better separate the usage of our Alchemy API keys. I want us to have clear visibility on the exact RPC usage from the specific ENSNode instances we are deploying on Railway and ensure we aren't using those API keys anywhere else.

• Note: Let's do a test here to better understand what causes the $RAILWAY_DEPLOYMENT_ID environment variable to change. When you update the environment variable config in Railway I assume it should restart each ENSNode deployment. When you do this, please check if it results in a totally new schema and totally new reindexing of all onchain events, or if the schema being indexed remains unchanged and that the ENSNode index continues indexing exactly where it left off.
  • Whatever happens here, please follow up with everyone on the team in Slack. It's important we confirm this for some of the other upcoming actions that are planned.
• Notify the team that they shouldn't use the Alchemy API keys configured in Railway for any other purpose than the Railway instances (they can continue to use the existing Alchemy API keys they are already using).
• Ensure that the "alpha.ensnode.io" ENSNode deployment has a completely new and unique Alchemy API key assigned.
  • Ensure we can track its usage at a detail level across Mainnet / Base / Linea (this deployment makes RPC calls to all 3 chains)
• Ensure that the "subgraph.ensnode.io" ENSNode deployment has a completely new and unique Alchemy API key assigned.
  • Ensure we can track its usage at a detail level on Mainnet (this deployment should only be making RPC calls to mainnet).

[BanaSeba]

I've created two new Alchemy apps for alpha and subgraph indexers. Populated env variables for two deployments accordingly.
We can easily track requests sent to specific chains by specific deployment.
Updating envs forces new deployment of each instance hence new schema will be created and a new sync process will follow.

[lightwalker-eth]

@BanaSeba Nice, thanks!

All your actions here look great 👍

Going to keep this issue in "Ready for Review" for a few days as a reminder to myself to review the usage metrics on Alchemy after a few days of collecting data.

[shrugs]

Update on this?