Best practices

Here is a list of items to check out before you deploy your squid for use in production:

• Make sure that you use batch processing throughout your code.

• Filter your data in the batch handler. E.g. if you request event logs from a particular contract, do check that the address field of the returned data items matches the contract address before processing the data. This will make sure that any future changes in your processor configuration will not cause the newly added data to be routed to your old processing code by mistake.

info

Batch handler data filtering used to be compulsory before the release of @subsquid/evm-processor@1.13.0. Now it is optional but highly recommended.

• If your squid saves its data to a database, make sure your schema has @index decorators for all entities that will be looked up frequently.

• If your squid serves a GraphQL API, consider:

  1. configuring the built-in DoS protection against heavy queries;
  2. configuring caching.

• If you deploy your squid to Subsquid Cloud:

  1. Deploy your squid to a Professional organization.
  2. Use dedicated: true in the scale: section of the manifest.
  3. Make sure that your scale: section requests a sufficient but not excessive amount of resources.
  4. Once you deploy, set a production alias URL to simplify subsequent updates. Use it and not API URLs of squid versions to access your API e.g. from your frontend app.
  5. Make sure to use secrets for all sensitive data you might've used in your code. The most common type of such data is API keys and URLs containing them.