I’m developing a provider to manage a fairly large amount of resources (10k+), therefore I’d like to implement some kind of caching to optimize the refresh phase (i.e. fetch all records in a single request, then respond from cache for read operations, instead of of doing a single request for each resource that needs to be refreshed).
So far I’ve tried a naive approach by caching records in the provider’s “meta” object, but it seems to me that a new meta object is instantiated for each provider operation, making my cache useless.
I was wondering if anyone has had the same issue and how you addressed it.
The protocol itself does not implement any sort of list/batch capabilities, which precludes there being an “easy” way to do this in provider code. All operations for managed resources are 1:1. In terms of trying to workaround that restriction, there are going to be implementation details of Terraform which would preclude or prove extremely risky to implement on the provider side, including but not limited to:
Terraform provides no contract that a provider server is kept for the entire length of a command. There can be multiple graphs for a single command and currently provider servers are restarted with each new graph execution.
Terraform’s graph provides no contractual ordering for nodes at the same level.
Practitioners can control the parallelism of Terraform’s node execution within the graph beyond its current default value of 10.
One potential strategy would be to consider having provider operations pause for a short period while waiting for others, but this sort of logic is generally complex to implement with little benefit other than likely making the provider slower overall depending on the graph of operations.
If the API call was known/consistent, then it would be a decent candidate for something such as sync.Once to save the response into a package scoped variable. However, that does not sound like your case since presumably the API call is dependent on the Terraform configuration.
There is Determine provider SDK strategy for minimizing API calls · Issue #7 · hashicorp/terraform-plugin-sdk · GitHub for tracking this type of enhancement on the provider side (it’ll likely get moved into a different repository now that terraform-plugin-framework is around), however any changes in this regard would be a major design change for both sides of the protocol. To that end, it may be worth opening an issue in the Terraform core issue tracker (Issues · hashicorp/terraform · GitHub) to ensure there is something capturing your specific use case. Ultimately, any efforts towards feasibility, design, and implementation would start on that side.
Great topic for discussion.