Would it be easy enough to separated the generated API with the Models via moko-network?

# moko

[Andy Gibel]

Would it be easy enough to separated the generated API with the Models via moko-network?

[alex009]

for now we use generated models only in domain (https://github.com/icerockdev/moko-template/tree/master/mpp-library/domain) module and all models and api classes is marked as internal. generated models we map to domain models (like here https://github.com/icerockdev/moko-template/blob/d6af0c09c5a6a5be15b42d37230c30691a72fed4/mpp-library/domain/src/commonMain/kotlin/org/example/library/domain/repository/NewsRepository.kt#L23)
and out of domain module we use manual-writed domain models, not api models.

[alex009]

you want use API models in business logic? i think (and in our experience it was) it not stable - server API may change structure of model and you need rewrite business logic to support new API model...but with mapping API model to domain model you just change mapper logic

[Andy Gibel]

Yes this is a hard requirement with our current architecture currently. Believe me I'm against it too :)

[alex009]

generated api models + api classes will be in same gradle module with business logic or it's different modules?

[Andy Gibel]

For instance, current setup is iOS only. Business logic library depends on a separate library that exposes the openAPI generated models and clients (only uses the models). The iOS client also pulls the openAPI models and clients directly. iOS uses the clients to fetch the models and then uses these models directly with the business logic library

[alex009]

so needed api models should not be internal visibility, but public.... i can in next release add gradle configuration to setup visibility. can you add issue on github with your case description?

[Andy Gibel]

Yep! Oh I see you have made them internal on purpose. To be fair in likely to fork your project anyway since I need a bunch of custom mustache templates

[Andy Gibel]

Another approach I'm considering is defining an expect/actual class with typealias with the ooenAPI generated models I already have for Swift and Java

[alex009]

custom templates can be also in your project, this not require fork of lib. we base on https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator-gradle-plugin so you can use templateDir in gradle config to setup custom templates

[alex009]

https://kotlinlang.slack.com/archives/CMC5LN42W/p1573008481007800?thread_ts=1573000509.004400&cid=CMC5LN42W
for what case is it?

[Andy Gibel]

Ok no fork needed, great. The expect/actual case I mention is to save me some work in the short term. It will take some time to integrate our custom parsers for Kotlin as right now I just have Java. I would like to leverage the existence of the Java and Swift models and focus on what I really care about - the shared business logic

[alex009]

parsing by kotlinx.serialization what applied by moko-network default not fit?

[Andy Gibel]

We use some custom fields that require special rules. I don't actually know more specifically at this time :).