https://kotlinlang.org logo
#moko
Title
# moko
a

Andy Gibel

11/06/2019, 12:35 AM
Would it be easy enough to separated the generated API with the Models via moko-network?
a

alex009

11/06/2019, 2:02 AM
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.
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
a

Andy Gibel

11/06/2019, 2:31 AM
Yes this is a hard requirement with our current architecture currently. Believe me I'm against it too :)
a

alex009

11/06/2019, 2:40 AM
generated api models + api classes will be in same gradle module with business logic or it's different modules?
a

Andy Gibel

11/06/2019, 2:43 AM
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
a

alex009

11/06/2019, 2:45 AM
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?
a

Andy Gibel

11/06/2019, 2:46 AM
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
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
a

alex009

11/06/2019, 2:49 AM
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
a

Andy Gibel

11/06/2019, 2:51 AM
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
a

alex009

11/06/2019, 2:54 AM
parsing by kotlinx.serialization what applied by moko-network default not fit?
a

Andy Gibel

11/06/2019, 2:55 AM
We use some custom fields that require special rules. I don't actually know more specifically at this time :).
2 Views