We decided to keep the WAR artifact in the root build directory so we didn’t have to change our existing deployment scripts. We had two options - in the root build directory or in the build directory of one of the child modules. We didn’t want the Kotlin Serialization default parsing options set by Spring BootĪlso since most of our APIs were packaged as a WAR file, we needed to decide where our WAR file should be built.Our build scripts couldn’t easily publish our multi-module artifacts to our Enterprise Nexus Repository.The API code was structured for use in a single module.So far the 7 APIs that have been converted to using Kotlin Serialization use either Spring Boot for our larger APIs and vanilla Kotlin (no framework) for smaller APIs which are deployed as AWS lambdas.Īlthough the concept of sharing our models is simple enough we still encountered a number of issues when implementing this. The strategy on our release train is to write all new APIs in Kotlin since it has many advantages over Java. The microservices at Auspost follow the RESTful API style, use JSON, and are mostly written in Java and Kotlin using a variety of Java frameworks such as Spring Boot and Spark Java. My previous article mainly focused on the client so let’s look at the changes required in detail on the backend. I always consider strategy in Software Engineering as a marathon, not a 100-meter sprint, changes take time to implement. We still have quite a few more APIs to convert, more teams to talk to and we may never hit 100% but it’s definitely a good start.

Twelve months later we now have 7 APIs using Kotlin Serialization for JSON parsing, these models are published to our Enterprise Nexus Repository and used by our Android App - this represents about 20% of all the APIs used in our App. We were never really sure about our strategy to share our API models with our clients would really work not because it was a bad idea but because we knew it would be difficult to get buy in from our API developers. Continuing on our journey from the article “ The first steps on your Kotlin Multiplatform journey - changing your microservices” that I wrote last year, I wanted to give an update on our progress and share some learnings.

Kotlin for backend