Skip to content
This repository has been archived by the owner on Jul 5, 2023. It is now read-only.

Latest commit

 

History

History
67 lines (47 loc) · 3.4 KB

which-sdk.mdx

File metadata and controls

67 lines (47 loc) · 3.4 KB
Raw
page_title description
Home - Plugin Development: Which SDK Should I Use?
A guide to help you pick the Terraform plugin development SDK that is appropriate for your provider.

Which SDK Should I Use?

There are two SDKs that you can use to build Terraform providers:

  • SDKv2 is what the majority of existing providers are built on, and it continues to provide a stable development experience.
  • Terraform Plugin Framework is a new SDK under active development, realigning the provider development experience and abstractions around the updated architecture of Terraform. It represents our vision of the future of Terraform plugin development.

This guide will help you decide whether you should continue using SDKv2, or begin using the framework.

Are You Writing a New Provider or Maintaining an Existing Provider?

If you maintain a large existing provider, we recommend that you begin migrating from SDKv2 to the framework by developing new resources and data sources with the framework. You can use terraform-plugin-mux to refactor the provider over time. Refer to the Migrate to Terraform Plugin Framework documentation for more details.

If you are developing a new provider, you should consider building it entirely with the framework.

Do You Have Bandwidth to Track and Resolve Breaking Changes?

The framework is still under development and its interfaces may change as we learn more about how providers are interacting with it. We will strive to keep these changes as small and as minimally disruptive as possible, but they are a possibility with the framework.

If you don't have the time, bandwidth, or tolerance for breaking changes, we recommend that you continue using SDKv2.

Do You Need More Features Than SDKv2 Provides?

The framework provides several features that are not available in SDKv2. You should consider using the framework if you would benefit from the ability to:

  • Tell whether a value was set in the config, the state, or the plan.
  • Tell whether a value is null, unknown, or the empty value.
  • Have structured types like objects.
  • Use nested attributes.
  • Use any type as the elements of a map.
  • Tell when an optional and computed field has been removed from a config.

Do You Need Any Features That the Framework Doesn't Provide (Yet)?

The framework is still under development, and so it may not yet support some features that are available in SDKv2. These include the ability to:

  • Use timeouts.

These features are on our roadmap to implement and support, but if you need them today, SDKv2 may be a better choice.

Can't I Just Wait Until the Framework Is Stable?

The framework doesn't have as strong a compatibility guarantee as SDKv2, so you may be tempted to wait until the framework matures before using it to develop providers. While this is a reasonable and understandable position, community adoption is important before we make a stronger backwards compatibility commitment. SDKv2 has over a thousand providers built on it, so we're confident in its interfaces. We want to make sure that the framework will also serve various API patterns well.

So where possible, we are hoping that you will help us exercise the framework, building confidence that its interfaces are appropriate for the next thousand Terraform providers. We look forward to your feedback.