Sub-optimal way of creating replicas

[greg0ire]

During yesterday's troubleshooting I mentioned in #134 with @julienpa and @godelized, they told me changing the primary to add replicas one by one was not the best way to proceed and had significant overhead. They hinting that one should gather the names of all replicas and perform a single set settings call on the primary. I don't have all the details, but they will comment on this issue.

[corps-fini]

Algolia is indeed capable of batching settings operations in certain conditions.
Changing the list of virtual replicas of an index might require an update of the primary index that could take some time, especially for a huge index. In this situation it's preferable to update the virtual replica list at once. In case of terraforming new (empty) indices, it's ok to update the replica list incrementally.

[k-yomo]

Yeah, we used to do the batch update with the replicas field.

terraform-provider-algolia/internal/provider/resource_index.go

Lines 104 to 110 in 7aca561

	"replicas": {
	Type: schema.TypeSet,
	Elem: &schema.Schema{Type: schema.TypeString},
	Set: schema.HashString,
	Optional: true,
	Description: "List of replica names.",
	},

However, it's difficult to support individual replica index resource for the config update while having the replicas field because it can cause conflicts and unexpected behavior.
(e.g. replica is included in the primary's replicas but the replica index resource is about to be destroyed)
Let me think about if there is a good way.

As a workaround, we can create multiple replicas from the console, and import it to terraform after.

[k-yomo]

We may want to include replica setting in algolia_index so that we can do batch update while making it possible to update individual replica. (If we do this way, then we should deprecate algolia_virtual_index resource)
The one of the cons of this way would be that it's gonna be a little cluttered and less readable.

resource "algolia_index" "primary_index" {
  ...
  replica {
    name = "replica_index"
  }
  replica {
    ...
  }
  virtual_replica{
    ...
  }
}

[greg0ire]

Another con that would impact us a lot would be that it would make it hard to avoid repetition between replicas: the replicas we have have very similar settings, so I created a module called products-virtual-replica to account for that and I can call that module several times with the settings that vary. With the syntax above I'm not sure how to avoid that repetition.

resource "algolia_index" "primary_index" {
  ...
  replica {
    name = "replica_index"
    languages_config {
      ignore_plurals_for    = [var.language]
      remove_stop_words_for = [var.language]
      query_languages       = [var.language]

    }
  }

  replica {
    languages_config {
      ignore_plurals_for    = [var.language]
      remove_stop_words_for = [var.language]
      query_languages       = [var.language]
    }
  }
  virtual_replica{
     ...
  }
}