Support for kotlinx serialization model generation

[simon-st]

I am looking to only generate the client models based off of Smithy specs. I will handle the actual network call myself, but would like to use generated model classes for the requests and responses. I would love to use kotlinx serialization for the deserialization of the responses instead of the current builder approach.

Questions:

1. Is there a way to only create the models and not the service class?
2. Do you plan on adding support for kotlinx serialization at some point?
3. Is there a way to define a model template or to influence the output models in any way without cloning and customizing the whole smithy-kotlin repo?

Thank you

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue, please leave a comment

Describe the Feature

Support for output models that can be parsed from a json string using kotlinx serialization

Is your Feature Request related to a problem?

Proposed Solution

Describe alternatives you've considered

Additional Context

• I may be able to implement this feature request

[aajtodd]

Is there a way to only create the models and not the service class?

Not currently. There has been discussion around this previously and generally seems like something we may want to support. There are a bunch of thorny questions to answer though and it's not something we plan to tackle in the short term. You can get around it by copying only what you need from the generated files though.

Do you plan on adding support for kotlinx serialization at some point?

No. The model already contains all of the metadata about how to serialize/deserialize (shape type, traits, etc). We would effectively be throwing this information away and instead generating a type that has to be (re)annotated with all of that context.

Is there a way to define a model template or to influence the output models in any way without cloning and customizing the whole smithy-kotlin repo?

What are you trying to accomplish? It's not clear what you are trying to do. You say you will handle the actual network call yourself, why? What is your use case?

[simon-st]

Thanks a lot for the reply @aajtodd.

The goal I am trying to accomplish is to keep our current client networking code that contains custom functionality for retries, error handling etc. It is taking us too long to manually create and maintain all the model classes though and it would be great if we could generate them from our existing Smithy definitions.
If we only want the models to be generated and not the service class, then using a json parsing library like kotlinx serialization would be much easier to use than manually parsing the json data into the builder classes (unless that is a way to automate this?)

[aajtodd]

Smithy is primarily an RPC framework and the main focus right now. We may consider this use case further in the future (being able to generate serialization/deserialization + models only) but it's not going to be anytime soon.

is to keep our current client networking code that contains custom functionality for retries, error handling etc.

I'm not sure where Smithy comes in here. Are you saying you are using a smithy based service? If so why not generate the client as well and figure out how to plug in your custom retry/error handling into the abstractions provided?

[simon-st]

Smithy is what our backend team is using to define their APIs and request/response models. I am fine to use the generated models, but am not really considering to use the full blown generated client for two reasons:

1. tbh, i could not figure out how to use it. There is no documentation nor examples - or at least I cannot find it
2. Related to point 1: smithy-koltin is currently in version 0.22.1 without any useful documentation, examples nor a large active community. I don't think the generated library would be ready to be used in a production app with millions of users - at least I would not feel comfortable to do so. We can re-evaluate once you reach v1.0.0

Anyhow, I do understand that you are currently focusing on the AWS environment. I think if, at a future time, you would want the kotlin codegen to be used outside of AWS, then generating models that can be used with a standard json parser would be a great feature.

[aajtodd]

tbh, i could not figure out how to use it. There is no documentation nor examples - or at least I cannot find it

This is a fair comment but we are also happy to help point you in the right direction. The biggest issue is what protocol is your backend using? Client behavior is dictated by an (application protocol) which dictates things like how errors are communicated, serialization format, etc. As an example the AWS restJson1 protocol semantics are described here.

I don't think the generated library would be ready to be used in a production app with millions of users - at least I would not feel comfortable to do so. We can re-evaluate once you reach v1.0.0

The version of the codegen does not dictate the production quality of it's output. In particular I doubt that we will mark it as 1.0 for quite some time as we aren't ready to commit to backwards compatibility of the codegen component. The generated code and runtime is a different story, those will come with much stronger backwards compatibility guarantees.

I think if, at a future time, you would want the kotlin codegen to be used outside of AWS, then generating models that can be used with a standard json parser would be a great feature.

This is a use case (generating non AWS smithy service clients) we care about now we just don't have any bandwidth for it. There also isn't a standard non AWS protocol definition to support right now (restJson1 is the closest to what most people would probably expect). You have to bring your own or use one of the AWS ones. If you're willing to roll up your sleeves we can likely help direct you how to accomplish what you want. In particular if you know what protocol is being used and it's semantics we can point you to how you would get that working. Most of the components are written (json serialization, http bindings, etc). You just have to glue them together. Generating "with a standard json parser" becomes irrelevant if you take advantage of the entire framework. This becomes even more important if your backend decides to start adding custom traits and things to the model, you don't have to hand write those things then, you can just update your own codegen to process them.

[simon-st]

Yes, these all all fair points. At the moment I am just not looking for a full client implementation, only for model codegen in a form that I can use them in our existing system. We are using a custom restJson protocol and have error handling already in place. We end up with the service response as a json string and using kotlinx serialization to parse it into the (currently hand written) model classes works very well. The only hiccup is converting unions to sealed classes. That is a bit weird, but doable with a custom serializer.
I think for now, the simplest solution is to adjust your generator classes for our needs on a fork. That seems pretty straight forward.