TL; DR : We, Backend-infra, would like to announce that we support Kotlin’s Coroutine as the framework to implement asynchronous process moving forward, replacing Callbacks. We encourage all engineers to start learning and writing Coroutine, to highly improve their code’s maintainability. You can start by using it for writing new codes/features or refactor old codes. Feel free to ask backend-infra to help you start using Coroutine!
Thanks to all of your feedback, we understand that Callback is hard to read, understand, and maintain. This brings extra overhead for engineers to pass and share context and knowledge to each other, develop features, and do debugging or incident handling.
But, we still believe that our engineering needs asynchronous. Asynchronous’ main purpose is to maximize throughput with minimum footprint e.g. infrastructure cost. The more the business grows, the more asynchronous becomes more important for us. Feel free to understand this argument better here.
To continue supporting asynchronous without sacrificing code maintainability, we searched a better solution than Callback, and we believe Kotlin’s Coroutine is the tool that we need. Coroutine enables engineers to write asynchronous code just like a synchronous one. Kotlin is also fully interoperable with Java, enables partial and gradual adoption. You can read more about Kotlin’s Coroutine here.
Multiple teams in our engineering, mainly universal search and accommodation had tested and adopted Coroutine. We asked the engineers about the experience, and it’s generally positive. We tried Coroutine ourselves by refactoring 2 complicated process written in Callback (we gathered it from engineers) into Coroutine, and we are satisfied with the code maintainability improvement (you can read about it here). We also presented Coroutine to customer experience team. @andy, a CX engineer, refactored one of their most complicated asynchronous code and generally he also got the same satisfaction as we had. The team has not adopted it fully though, and we are still observing the adoption process. Overall, based on these feedback, we believe Coroutine will bring benefit for your team as well.
We highly encourage all engineering teams to start learning and writing Coroutine given its benefit and good experience from early adopting team. Kotlin is fundamentally a new programming language though, please discuss internally whether all engineers in your team are OK having a code in the codebase written in non-Java. We also are observing team that are trying Kotlin but for other purposes beside Coroutine, mainly for its concise syntax and nullability & immutability checker. So far, we are confident that our engineering will write more Kotlin code in the future.
Feel free to ask backend-infra to help for Coroutine (or Kotlin) adoption in your team. More Coroutine adoption will give us more insight to determine what’s next to improve our engineering. There’s also #kotlin channel!
We also would like to use this opportunity to thanks all of our collaborators for this project, especially Ismail, Shunyuan, Bobby + his team, and #kotlin
:bow::skin-tone-2:Last but not least, your feedback are always invaluable. Feel free to give inputs, try our initiative, or share your interesting research!
Thanks2!
:bow: