Provide function name as parameter to serializer/deserializers

[hongyiweiwu]

Currently when we implement custom serializers we have to figure out what function the message is for from the message itself. In my code I have to include the function's name as a property inside the message. It would be helpful if the function's name can be provided as a parameter to the serialize/deserialize function.

I can do a pull request if you like. Let me know how you think.

[andywer]

Hey @hongyiweiwu!

Interesting point, but I don’t think it can work like that. I assume your use case is serialization of arguments while calling a method exposed by a module worker.

You don’t have a function name in any other case, though: Function workers, serialization of return values, callbacks (#273), recursive serialization, …

Another issue would be that the method name alone is also not worth much as you can easily have multiple different workers exposing methods with the same name.

Serializers should in theory only care about what to serialize, not for whom.
👉 I am curious why you care so much about the called function and not the content of the passed arguments?

[hongyiweiwu]

Hi @andywer! Thanks for replying!

You're right, I'm using this for module workers. The reason I need this is that I'm designing the module worker functions so each one takes a JSON object containing all the parameters it needs. In this way, I can use Fastify's JSON serializer which is a lot faster than the default one. To use it though I'll have to specify a JSON schema for each type of the payload, and call the serializer on that schema first. So I'll have to know, during the serialize call in the threadsjs serializer, which function is the payload for, so I can select the appropriate schema.

Hope this makes sense.

[andywer]

Alright, but then you can just add a type property to each of those JSON objects to specify what kind of message that is and use this to tell them apart, not?

Also from a logical sense it makes more sense to serialize by the type of message, not be the recipient. Maybe you have two functions that expect the same input.

I wonder… is there is any reason against the type prop?

Bottom line my two main concerns here are:
a) that the reason for the requested feature is based on an approach that seems to be in conflict with best practices (define what to serialize, not for who) and
b) that the proposed feature will only work when calling module workers, not for any other situation the serializer is invoked for.

[hongyiweiwu]

Not really lol, it's just kind of verbose that whenever I'm calling the function and I'm preparing the payload I have to include the name of the function inside the payload so the serializer can distinguish. But I do see your point, and it's not an elegant design to include the function name as a parameter from a library perspective.

I'm closing the issue. Thanks for the response!