Introduce internal/fwserver package and migrate GetProviderSchema #319
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reference: #215 This step of the provider server refactoring introduces a new `internal/fwserver` package that will contain the provider server implementation for any protocol version, there only being a version 6 implementation at the moment. This package will contain only framework-native types that aren't already defined by the `tfsdk` package that are used by provider developers today, which is necessary to prevent import cycles. The protocol specific implementations will then wrap this framework server implementation and handle any necessary conversion of protocol specific types to framework specific types and back. Eventually, the existing `internal/proto6server` implementation will make no reference to any framework native types except the framework server and protocol type conversions. For now, only the `GetProviderSchema` RPC is migrated to show what this refactoring will look like for the rest of the RPCs. This has a few benefits which can be seen here including clear abstractions for protocol specific handling versus generic framework handling and unit testing at those abstraction boundaries.
bendbennett
approved these changes
May 6, 2022
There was a problem hiding this comment.
I really like the direction this is going in, a distinct separation of concerns for protocol-specific and framework-specific handling is a great idea and makes logical sense. I have to be honest though and confess that I didn’t look at internal/toproto6/getproviderschema_test.go. Great work Brian!
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reference: #215
This step of the provider server refactoring introduces a new
internal/fwserverpackage that will contain the provider server implementation for any protocol version, there only being a version 6 implementation at the moment. This package will contain only framework-native types that aren't already defined by thetfsdkpackage that are used by provider developers today, which is necessary to prevent import cycles. The protocol specific implementations will then wrap this framework server implementation and handle any necessary conversion of protocol specific types to framework specific types and back. Eventually, the existinginternal/proto6serverimplementation will make no reference to any framework native types except the framework server and protocol type conversions.For now, only the
GetProviderSchemaRPC is migrated to show what this refactoring will look like for the rest of the RPCs.This has a few benefits which can be seen here including clear abstractions for protocol specific handling versus generic framework handling and unit testing at those abstraction boundaries.
Please note that much of the "end-to-end" unit testing is already in the
internal/proto6serverpackage, which shows no changes in behavior, and therefore can help gain confidence in this change not introducing potential regressions.