I have a bit difficult time scoping how large or small the components should be. There’s general recommendation to avoid factories (eg. for_each) inside a component. Now, if I take managing Cloudflare DNS records as example, this would mean every single DNS record should be it’s own component instance. Perhaps in this case it would be better to put that DNS record within other components directly where it it needed, but on another hand, there’s also recommendation to limit providers to one or two per component. For example: I now have a component to create GKE cluster. I have a separate component for enabling GKE gateway, which includes google provider, kubernetes provider (to create gateway manifest), TLS provider for provisioning custom origin cert, and cloudflare provider to create record that points to gateway IP and set the origin cert there. Is this too small, too big, or right size? 😄 Another requirement I have is ability to provision API keys (like google maps, Vertex etc.). Currently I am planning to have them right in the component that does entire project creation, as having one component to create API keys, or worse, just one type of API key, sounds a bit silly.

Hey Paavo, I like to think of components as Minimal and Reusable. Minimal, as in the bare minimum needed to setup a working version of my resources. Reusuable, as in I can call my component over and over to create multiple instances or versions of said component. I'll use AWS resources as an example, I have a shared ALB that requires an SSL certificate, Route 53 hosted zone, security group, S3 bucket (for logging) and maybe even an IAM role. I could make each of those requirements a component as well, but a component of components doesn't scale very well, so my component wraps all those resources into one single unit

Yes, it's a fair question. There's no steadfast rule. For example, with resource records (RR) on zones, it would likely make sense to manage them together. But where you may run into problems is if you're managing 1000+ resource records for a single zone. In this case I would design it so a collection of resource records can be managed together.

Depending on the component, and the level of flexibility, I might create a terraform variable that let's me turn off say the HTTPS listener as an example (not that I would ever do that for real). The point is the ability to include or exclude sub-components at will