Thanks for the recent tutorial <@U02SEA99VJB>. One...

# akkurate

[rocketraman]

Thanks for the recent tutorial @Johann Pardanaud. One gap I see with using data classes in API interfaces is that immutable strongly-typed data classes aren't often a great fit for receiving "messy" data at the API level. For example, if a value is required, it has to be given a "default value" -- in your tutorial you used an empty String, but that introduces some noise into the data model.

Furthermore, errors can be thrown in advance of validation -- kotlinx-serialization may not even be able to create the data class if the types or fields don't match. Also, implementing capabilities like PATCH is impossible to do with the same types, because the incoming data is incomplete, so even if the server-side code can deserialize it (unlikely), we still need to know which subset of fields was actually sent by the client.

I had implemented https://github.com/rocketraman/kpropmap to deal with these scenarios in the past. The idea is to receive the data from the API in a flexible way, and then do validation and conversion to the strongly typed model on the server-side.

Any thoughts on introducing a similar capability to Akkurate? I've long wanted, but haven't had the time to have kpropmap use KSP and kotlinx-serialization rather than runtime reflection, and Akkurate already uses these tools.

[Johann Pardanaud]

Hi @rocketraman, thank you for the feedback! Your library is really interesting (just starred it ⭐ ) and I totally get why you've created it.

Essentially, I've designed Akkurate to be as simple as possible in its core. Its job is limited to validating existing class instances, not to manipulate the raw payloads of the HTTP request. This allows to bridge Akkurate with almost any tools, since its working with basic classes.

One gap I see with using data classes in API interfaces is that immutable […] data classes aren't often a great fit for receiving "messy" data at the API level.

I always demonstrate Akkurate with data classes because I think it's better this way. But, actually, you can also work with simple classes. Do you mind telling me if you thought about Akkurate being limited to data classes? If so, I will try to clarify this in the documentation.

Furthermore, errors can be thrown in advance of validation

You're right, and this is something where Akkurate can't help, unfortunately. However, there are some ways to mitigate some of the issues you mention:
• configuring kotlinx.serialization to ignore unknown properties
• providing default values for your properties to allow partial payloads
• and since you don't want to "introduce some noise into the data model", you can create DTOs (yes, you will have to map them 😕)
I know I'm not really answering to your requests there… but Akkurate hasn't been designed to work close to the HTTP payload, essentially to keep its API simple and to allow easy integration with other tools.

However, I will keep in mind what you wrote here because you have valid points, and maybe one day I will find some way to improve Akkurate for those use cases. 🙂

[rocketraman]

All fair points, and totally understand the design goals of Akkurate. Good to know that it works on regular classes, not just data classes -- I didn't realize that but its not any fault of the docs -- I just haven't delved deeply into Akkurate yet.

I'm very much looking forward to trying out Akkurate on my next project. I haven't used kpropmap myself recently because most of my recent projects have moved to GraphQL or strongly typed RPCs, so kpropmap just isn't needed. However, if I ever get back to working on kpropmap again, I'll think about how it could leverage Akkurate under the hood for validation instead of implementing its own validation layer.

[Johann Pardanaud]

Actually, I had the idea of Akkurate when I was working with gRPC. Which is why I never thought about handling partial payloads or missing properties 😁