--
As you might know we are big fans of infrastructure-as-code and applying this technique to pretty much any cloud and SAAS service we work with. In fact we believe this should be the ‘standard’ approach to configuration management of SAAS services in the MACH space, as it provides a first-class developer experience for configuration management. So when we started working with Amplience, creating a provider for it was the first thing we did!
The first time we built a Terraform Provider ourselves was for the commercetools platform, back in 2018. This proved to be the right decision; today the provider is fully featured and used across the entire commercetools partner & developer ecosystem. And it is also what propelled our thinking towards MACH composer, our orchestration framework built on top of Terraform.
The headless SAAS CMS Amplience is no exception for this approach. We started working with Amplience about two years ago, and when we started with it we immediately created a Terraform provider for it. We use it to manage the configuration of several production environments, both small and large scale and in combination with MACH composer.
We believe infrastructure-as-code should be the ‘standard’ approach to configuration management of SAAS services in the MACH space.
With the provider we can manage most of Ampliences configuration through infrastructure as code. In practise, this means that you manage your content repositories, types and type schemas with it. Although other resources are supported as well, such as managing search indexes and webhooks. See below for some examples.
The provider does not cover all configuration options of Amplience yet; we implement features whenever we need them ourselves in our projects. PRs are always welcome!
To get started with the provider, see its documentation!
Or have a look at the Github repository.
In Amplience, content types and content type schemas are managed with JSON. With Terraform we manage these JSON files in the Amplience API, like below.
resource "amplience_content_type_schema" "url" { body = file("path/to/url-schema.json") schema_id = "https://mysite.net/url" validation_level = "CONTENT_TYPE"}resource "amplience_content_type" "url" { content_type_uri = amplience_content_type_schema.url.schema_id label = "URL" status = "ACTIVE"}
As you might have read earlier on our blog, we have also built a GraphQL code generator for Amplience, which conveniently generates Terraform code as well as the JSON schemas, off of a GraphQL schema you define.
Of course webhooks are supported. This an area that Terraform specifically shines, as you can mix & match different cloud services with each other quite easily. In the below example, a custom payload is sent to an HTTP endpoint, whenever a content item is archived in the Amplience CMS. In that case, a DELETE request is sent to the HTTP endpoint.
resource "amplience_webhook" "topics_webhook_delete" { label = "mysite_topics_webhook_delete" events = [ "dynamic-content.content-item.updated", ] handlers = [ "https://myendpoint.com/amplience/topic", ] active = true secret = var.secrets["AMPLIENCE_WEBHOOK_SECRET"] method = "DELETE" filter { type = "equal" arguments { json_path = "$.payload.status" value = ["ARCHIVED"] } } custom_payload = { type = "text/x-handlebars-template" value = file("${path.module}/custom-payload/topics-delete.json") }}
Using the provider means that you can manage Amplience’s entire system configuration in version control. This allows for better grip on managing the system, and makes it easy to scale across many environments (including setting up development environments). Also, through the use of webhooks in conjunction with other Terraform providers (i.e. AWS Lambda or API Gateway configuration), integration into your composable architecture becomes very easy to implement and manage over time.