🌟Best Practices

Useful practices and conventions for effective indexing

🪄 Start small with a limited use-case

To get yourself familiar with event indexing, start with a small pilot for your project or protocol. This allows you to try the indexer and develop further as your requirements and needs come up.

An examples of where to start:

Gather all your contract events in real-time, and then aggregate Totals for your protocol, such as Total Deposits, Total Amount Withdrawn, Current Balance. Then use that as internal analytics. When you're happy with the accuracy of the data, expose that single value to your frontend for your users.

🪄 Build for a distributed environment

Due to the asynchronous nature of parallelized blockchain indexing, events may be received out-of-order or multiple times because of retries.

Account for idempotency and re-orgs. Consider these tips:

• Ensure updates occur only with the latest data.

  • Flair's managed database interface handles such cases using a horizon attribute featured in all example codes.

• For upstream scenarios that don't support idempotency (e.g. Discord messaging), use Flair's managed cache interface to "remember" already completed calls.

🪄 Development vs Production

In early stages, a single cluster may suffice. However, after initial production deployment, it's best to use separate clusters and namespaces for production and development.

Consult our engineers for production-readiness advice, such as monitoring, alerting, pre-provisioned capacity, and more. Reach out to our engineers 🙂

🪄 Write > Deploy > Backfill > Logs

Follow the steps in the Starter Boilerplate for a robust custom processor development and a quick feedback loop. Ensure everything works as expected by checking logs and querying the data.

🪄 Lower-case addresses

A common mistake that causes long debugging sessions is using the wrong casing for addresses (wallets, contracts, etc).

It is recommended to always lower-case addresses when writing or reading the data, to make sure despite user's input you always get the consistent result.

🪄 Remove the test data

During your development you might create test entity data that you can remove to reduce your storage costs.

Visit https://graph.flair.dev, on the example tabs on the top scroll to "Delete Entities by SQL", which allows you to write a SQL query that returns a list of "entityId"/"entityType"s that will be used to delete entities (only if your API Key have access to the namespace).

If you need any help reach out to our engineers.