docs
docs copied to clipboard
Document what makes a good SDK server for Composition Functions.
@negz maybe this isn't the best place for this, maybe its better as a conversation in Slack.
What's Missing?
I have a simple GPRC server based on the Function protobuf working in Java, but I would like to turn it into something reusable and possibly distributable as an SDK.
I have a few items on my checklist that I was wondering about that don't seem to be documented anywhere.
-
The Go SDK has a --insecure flag which I assume enables/disables TLS, what are the TLS requirements for crossplane to communicate with the server in a running environment? I have only tried this thing via the CLI and wondering what kind of issues I will run into when I package it up in a container and publish it.
-
The GO SDK has some utility methods to do things like add a result.
response.Normalf(rsp, "I was run with input %q!", in.Example)
Is there a list of what convenience function should be present in order to be considered a proper SDK? -
I am completely removing the protobuf and remapping the objects POJOs to avoid developers having to worry about dealing with Structs in Java. Additionally I usually try to prevent generated DTOs from leaking into the business logic so that if the transport changes over time the function itself does not need to change. I map them back to a protobuf before returning the result. Thoughts?
The Go SDK has a --insecure flag...
https://github.com/crossplane/crossplane/blob/v1.14.2/contributing/specifications/functions.md is a first pass at some of this. In particular it describes required flags like --insecure
and how they should behave.
Is there a list of what convenience function should be present in order to be considered a proper SDK?
No. It's too early to know this yet. I'm also not sure it will ever be obvious enough to write them down. Something that makes sense in one language may not make sense in another. For now, you could look to any commonalities between https://github.com/crossplane/function-sdk-go and https://github.com/crossplane/function-sdk-python
Thoughts?
I'm a Java novice, so I don't understand the question fully. 😄 That said, my intuition is that trying to completely abstract away the generated protobuf code might incur a lot of ongoing SDK maintenance burden for relatively little gain.