[REQ] Language specific configurable serializers

Problem scope of this request

When generating code via the code generator process, the generators include specific serializer implementations as part of the generated code for handling (de)serialization of the models.

For example, if I am using the java generator, right now I automatically get the Gson serialization library as part of the generated code, however if I am using a client / server that already contains it's own serialization implementation (ie. Jackson), then I now need to have 2 serialization implementations on my classpath.

Another example I noticed when generating code via the kotlin generator was that Moshi was included by default (which only handles JSON to my knowledge?). However there are also other implementations of serializers that are a bit more flexible that exist (ie. kotlinx.serialzation).

Proposed solution

I would be looking for a means to configure what serializer implementation to use based on the request / response types I have defined in my OpenAPI spec and the language of the generator I am using. But have the serializer implementations be mapped to the the handled request / response types that might be defined in the OpenAPI spec being used.

For example, if I have an OpenAPI spec that has custom schema models being used as application/json and application/xml types, including the Moshi serialization implementation would not work when generating code to handle both request / response types.

As part of the code generation process, I would propose that the generator introspect the complete list of all request / response types (ie. application/json / application/xml / application/protobuf etc), or introspect what models are being mapped to what media types. Then the generator should be able to have a lookup table of Language -> Serializer_Implementation, where each Serializer_Implementation would contain it's own List<HandledMediaType>.

The generator would then be able to pick the least number of Serializer_Implementations that would fit serialization of all handled media types for that OpenAPI spec.

Or on the flip side, the user would be able to configure the Serializer_Implementation they would like to use in their generated code, and the generator would write the appropriate code for that serializers implementation IFF that Serializer_Implementation chosen by the user actually handles the media types they have mapped in their OpenAPI spec. For example if they configure the generator to use Moshi but have schema models mapped to application/xml media types, the code generation should fail fast and report an error.

Alternatives I've considered

I might be naive here, but just wanted to flag this as something that wasn't obvious to me when dealing with serialization of the generated code models. I have considered writing my own generator / template for the serializer implementations I would want, but unsure if that's the right path forward since it's high lift to spin up a new generator specifically for changing a few minor things based on the serializer implementations one would like to use.

Start by tracing the code generator process and the language-specific generators that add serializer implementations for generated models. Define how request and response media types are discovered, how serializer implementations declare handled media types, and how configuration or unsupported media types should be reported; done means the design is agreed and covered across the affected generators.