Why is serialization managed globally? What's the price of managing it locally?

At the moment, we are using Camunda Spin Jackson plugin to manage serialization, which is causing several headaches in development and production.

In particular, because we use Scala classes which jackson doesn’t forcely serialize as we expect, we have a plugin which sets custom serializer and deserializer for some of our classes. Sometimes we add new classes to our processes, we forget they might need some custom serializer/deserializer and the code explodes at runtime.

We are considering to write an API on top of the process engine which would instead force anyone saving non primitives values on a process to provide at compile time appropriate serializer, much like so

public void setVariable(String processInstanceId, T variable, Serializer serializer){

}

where the Serializer will typically always produce a byte array. What sort of penalty we might be paying for this approach? Would we lose something in terms of process engine? For example, when deserializing, we could smoothly handle schema evolutions which we don’t at the moment (if we have a very long process, we might have to bring it back to the beginning to retrieve from remote services the new model of previous api) because a developer might put a deserializer that is able to default that missing value for that class.

That sounds like a valid approach to me. To answer the title question, serialization is managed globally to save users the effort to do it themselves. But it’s perfectly fine to do just that in your scenario. I don’t think there is a price in terms of performance. Conceptually, you may not be able to meaningfully deserialize the values without having the serializer at hand (e.g. when accessing from Cockpit), but in case of JSON this is probably fine.

As a side note, in your custom API implementation you could set the variable as a Spin Json Value (instead of a byte array), which would enable inspecting its value from Cockpit.

1 Like