What problem are you facing?

We've been using the composition functions basically since day one. When starting with them, we had lengthy discussions how to handle the objects.

We decided to use and import the already available go structs that most providers have (provider-kubernetes, provider-helm, etc.). This makes working with the objects a lot more comfortable, as the compiler will help with type checking.

While there's a composed.From(rutnime.Object) function there's no function for the other way round e.g. composed.To() witch could marshal the composed resources directly into a typed object.

Additionally, it might make sense to change composed.From(rutnime.Object) to composed.From(resource.Managed) to avoid adding a plain k8s object to the desired state. We've had the issues before that someone added plain k8s objects without wrapping them in a objects.kubernetes.crossplane.io first. Which can lead to very annoying to debug bugs.

Also, it might be worth adding functions to response to directly add objects to the desired map.

For example:

response.AddDesiredComposedResource(resp RunFuntionResponse, o resource.Managed, name string)

Which would do the marshalling and add (or override) the given object in the desired composed objects map.

IMHO these changes would greatly improve the developer experience of the SDK. It also helps to avoid errors like here: #68

I've already implemented such typed functions in our framework: https://github.com/vshn/appcat/blob/change/xplane114/pkg/comp-functions/runtime/function_mgr.go#L282
And it's working great so far, it's already a lot better than the previous runtime.RawExtension in the FunctionIO.

How could Crossplane help solve your problem?

It already does, these are just suggestions to make it even better. :)