Creating a Desired Composed Resource with []map[string]interface{} fails when setting Object about function-sdk-go

[blakeromano]

When I update code to I do not get an error

	desired.Resource.Object = map[string]interface{}{
		"apiVersion": "s3.aws.upbound.io/v1beta1",
		"kind": "BucketServerSideEncryptionConfiguration",
		"metadata": map[string]interface{}{
			"name": oxr.Resource.GetClaimReference().Name,
			"namespace": oxr.Resource.GetClaimReference().Namespace,
		},
		"spec": map[string]interface{}{
			"deletionPolicy": "Retain",
			"forProvider": map[string]interface{}{
				"region": "us-east-2",
				"bucketSelector": map[string]interface{}{
					"matchControllerRef": true,
				},
				"rule": []interface{}{
					map[string]interface{}{
						"applyServerSideEncryptionByDefault": []interface{}{
							map[string]interface{}{
								"sseAlgorithm": "AES256",
							},
						},
					},
				},
			},
			"providerConfigRef": map[string]interface{}{
				"name": "aws-provider",
			},
		},
	}

Yeah I am taking a first stab at XFNs so if there is a better way to import resource types and do it that way I'd love to see some examples.

[negz]

@blakeromano Does it work if you make rule an []interface{} where the values happen to be map[string]interface{}?

As a side note, working with unstructured interface data like this feels likely to be unintuitive and error prone. For managed resources like BucketServerSideEncryptionConfiguration we could probably import the go types from the providers and use those. I'd like to add some examples of that pattern.

[negz]

@blakeromano The reason behind the this behavior is that there's an assumption that Object will be a map[string]interface{} containing values in the shape that https://pkg.go.dev/encoding/json#Unmarshal would create when unmarshalling JSON into a map[string]interface{}.

See:

• https://github.com/crossplane/function-sdk-go/blob/0a4b30c5/resource/resource.go#L97
• https://pkg.go.dev/google.golang.org/protobuf/types/known/structpb#hdr-Conversion_to_and_from_a_Go_interface

One thing we could do here would be to make this clear in the error that you hit.

[Kidswiss]

@negz it would be nice if the SDK interface would just accept runtime.Object and do the serialization to unscructured in the background.

As a side note, working with unstructured interface data like this feels likely to be unintuitive and error prone. For managed resources like BucketServerSideEncryptionConfiguration we could probably import the go types from the providers and use those. I'd like to add some examples of that pattern.

We did something similar with the alpha FunctionIO, although then it was mostly raw []byte, but the concept is the same. We import the managed resource structs wherever possible and work with those. Then we wrote some tooling to marshal them seamlessly.

For example to get the composite: https://github.com/vshn/appcat/blob/master/pkg/comp-functions/runtime/desired.go#L155
And then it's easy to get any typed object back: https://github.com/vshn/appcat/blob/master/pkg/comp-functions/functions/miniobucket/miniobucket.go#L28

Would you be open for a PR that implements something similar with the function-sdk-go? I'm currently in the process of adjusting our code to crossplane 1.14 and it would be really great if function-sdk-go could provide APIs for typed objects.

[negz]

I'll close out this issue. I'm not sure what next steps are here. I think maybe the most interesting thing here is that some folks want to (or at least intuited that they should) work with functions by setting the unstructured Object directly, which is not really something I expected. If that becomes a trend we may need to point folks at documentation (e.g. upstream Go documentation) WRT expectations around building a JSON-compatible map[string]interface{}.

@Kidswiss Can you raise a dedicated tracking issue for improving the support for working with runtime.Object? Ideally with a proposed API. I'm open to changes to support that better.

We do already have (e.g.) composed.From() to create a new composed resource from an arbitrary runtime.Object, But we don't have anything going the other way - i.e. to load the desired XR into an arbitrary runtime.Object.