Hey, I'm looking for a simple solution that doesn'...

# ktor

[Manuel Pérez Alcolea]

Hey, I'm looking for a simple solution that doesn't lead to messy code for this specific problem. I'm using kotlinx.serialization to serialize data classes to JSON, which look a bit like this (not really, but let's assume:)

data class TheData(
  val postId: Long,
  val content: String,
  val authorId: Long,
)

These represent the content stored in the database. Now, when serialized to JSON, I want a few properties to be serialized "in a different way," and only in the context of sending it to a regular user. Instead of this:

{
  "postId": 500,
  "content": "hello",
  "authorId": 322
}

I want them to get this, if (in the backend) I check the entry has been created by the requester:

{
  "postId": 500,
  "content": "hello",
  "bySelf": true
}

The simplest solution I can think of would be to create a new serializable data class ThePublicData and convert TheData to them accordingly. Are there any elegant solutions for this? Should I avoid having a single class for multiple use cases in serialization? Hmm, I reading the official guide on polymorphism, I might find something useful.

[Christos Malliaridis]

You may consider using custom serializers or two different data classes.

In backends developers often differentiate between incoming request data models, processing data models, outgoing data models and persistent data models. So mapping one object to another may be beneficial, as it may add consistency to your project and clear separation of concerns between each step / service.

[Manuel Pérez Alcolea]

Got it, thanks. It sounds like what I had intended, but if I went for the custom serializers approach, could I have a way to easily "switch" between them in ktor? e.g. you would commonly use call.respond(myObject) to send a response, but what if I want to serialize it in two different ways depending on who the response is for? Different data classes world work (myObject.toSomeOtherModel()) but can it be done without new class definitions, and only with multiple serializers for the class? It sounds weird so I'm not asking for this solution, more like if it should be done like that and if it's feasible

[Christos Malliaridis]

If you could not make use of any of the solutions from the custom serializers link you would probably go for the last option and provide two different serializers and select the serializer you want (like here) with an if-else condition and handle yourself the serialization of the response data.

But I personally prefer multiple data classes over custom serializers, it looks in my opinion cleaner and is easier to maintain. Doc comments would come in handy in this case, you could document data classes and fields as well as their usage. And once you don’t need a field anymore or need to add one, you don’t have to mess around with the serializers logic, but instead you can simply add or remove the field from the data class and update if necessary the mapper.

I think this is pretty much a preference and very case-specific you situation. Therefore, decide which solution looks best to you and go for it. You could also implement all options in question and decide by comparing the solutions in various scenarios.

[Manuel Pérez Alcolea]

Understood, many thanks.