Extension for Aspect-orinented programming / Visitor Pattern

[iggyzap]

Hello,

While working with Terraform (after worked with AWS CDK for Typescript) I've realised that for Terraform / OpenTofu language to be capable of customisable / versatile abstractions (i.e. modules) it lacks a mechanism to customise resources inside a module.

I'll expand on this - let's imagine a scenario when a module's author provided designed for one simple function - create a Load Balancer (ALB) pointing to ECS backend in AWS with correct DNS entries for ALB and generate SSL certificate for the ALB.
The author did not envision that the user might want to issue the certificate with additional names to cover for extra services - let's say CloudFront CDN for frontend, which sits on the subdomain of the app.

Such module to be useable will have to either way to customise certificate subject or provide alternative names, which can result in person who wants to use the module to come back to author with PR to enable such a feature.
Over the time module interface grows - now it has every possible option customisable as a passable variable, but quick glance at it API surface scares people because it became a monster of 250 variable with arcane sense.
( I am looking at this module as an example of exploded complexity - https://registry.terraform.io/modules/terraform-aws-modules/vpc/aws/latest )

One of the approaches to combat such explosive complexity is to implement a mechanism for a module user to customise resources inside a module with mutating visitor that if presented during module life-cycle will apply a transformation to the resource, for example in our scenario it will add extra subject alternative names to the certificate.

What people think ?

With regards,
Ignat Zapolsky

[abstractionfactory]

Hi @iggyzap thank you for this post. We have received requests in the past to break module boundaries for various reasons and they have been rejected.

AOP fundamentally circumvents any boundaries present in the code, such as module boundaries. This is a problem because the module author cannot expect every possible scenario where an internal local or value has been modified from the outside and consequently, the module may break in entirely non-obvious ways when upgrading.

Most requests around this are because people shy away from forking a module because it would put the burden on them to review any updates and maintain a fork. However, AOP only moves the problem to a less visible place even in the best case as people have to review each and every update to the module anyway. In the worst case this serves as a workaround for corporate and regulatory controls, which, needless to say, we do not want to support.

If a module doesn't behave the way it should, it should be forked and modified to suit the use case. If the module is too complex, it may have to be broken down because it is fragile anyway.