Remote
A very silly idea to use a Codec Server to encode and decode your payloads
Why is this a silly idea?
This will be a huge bottleneck. Temporal is designed to be fast. Encoding,
especially AES, is an expensive process by design. This will probably make your
Temporal calls slow and potentially unreliable. Temporal is a highly scalable
service.
This Codec Server is not.
Also, the POST:/encode endpoints are, by design, unauthenticated endpoints. So
this can be open to anyone who wants to use it. They also won't be able to decode
anything that comes out of it.
Why did you build it then?
I wanted to see just how bad an idea it is. All my brilliant Solutions Architect
colleagues say we shouldn't do remote data conversion. And they understand why
because they've experienced people who have done it.
But I haven't done. By seeing how silly an idea this is why allow me to better
advise the people I work with and advise.
I'm the sort of person who, when told by waiting staff "be careful, that plate
is hot" checks just how hot it is. 🔥
Simon Emms - taking pain in the name of empiricism since 1982.
Ok, how do I use it?
go get github.com/mrsimonemms/temporal-codec-server/packages/golang
package main
import (
"github.com/mrsimonemms/temporal-codec-server/packages/golang/algorithms/remote"
"go.temporal.io/sdk/client"
)
func main() {
// The client is a heavyweight object that should be created once per process.
c, err := client.Dial(client.Options{
DataConverter: remote.DataConverter(
// Replace with the URL you want to use
"http://localhost:3000",
// Add any HTTP headers to the calls
map[string]string{
// The server can support HTTP Basic headers with the BASIC_USERNAME/BASIC_PASSWORD
// headers - this is "username:password". This is useful if you want to
// have user authentication provided by Temporal Cloud, but want a way
// of allowing dev users access
"Authorization": "Basic dXNlcm5hbWU6cGFzc3dvcmQ=",
},
),
})
if err != nil {
panic(err)
}
defer c.Close()
// Continue...