扩展 kmp_更改微服务的kmp旅程的第一步-CSDN博客

扩展 kmp

The mobile apps that we use today wouldn’t be very useful without APIs and the same can be said about APIs — without nice UIs the information from calling APIs isn’t very consumable. When I first started in mobile development many years ago I always had the dream of creating reusable SDKs for our internal APIs to make integration faster and easier on our apps. Just for clarity, our internal APIs are internet-facing however they can only be consumed using an authenticated token and by our own clients. So why couldn’t we provide SDKs just like the big tech companies provide for their public-facing APIs?

如果没有API，我们今天使用的移动应用程序将不会非常有用，关于API的说法也可以这么说-没有出色的UI，调用API的信息就不是很消耗。多年前，当我刚开始进行移动开发时，我一直梦想着为内部API创建可重用的SDK，从而使我们的应用程序的集成变得更快，更容易。为了清楚起见，我们的内部API面向互联网，但是只能使用经过身份验证的令牌和我们自己的客户端使用。那么，为什么我们不能像大型科技公司为公众提供的API一样提供SDK？

As it turns out creating and managing SDKs can be a very time consuming and expensive proposition especially when you have to support multiple platforms such as Web, Android, iOS and the JVM. The big tech companies have the resources and the money to do this but what can be done if you work in the enterprise or corporate world? Most corporates tend to use either Java or C# for their backend/APIs and if you happen to work a Java shop then you’re in luck. Fast forward to 2020 and a framework called Kotlinx Serialization now makes it a reality, you can easily build a partial SDK with little effort and start sharing it amongst your clients.

事实证明，创建和管理SDK是非常耗时且昂贵的提议，尤其是当您必须支持Web，Android，iOS和JVM等多个平台时。大型科技公司有这样做的资源和金钱，但是如果您在企业或企业界工作，该怎么办？大多数公司倾向于将Java或C＃用于其后端/ API，如果您碰巧在Java商店工作，那么您会很幸运。快进到2020年，现在称为Kotlinx序列化的框架使其成为现实，您可以轻松构建轻松的部分SDK，并开始在客户之间共享。

Now let’s jump back to the past for a while and look a previous attempt in my life to do something similar. I’ll also explain why I call it a partial SDK later on. A few years ago, Australia Post embarked on an ambitious project to create a product called Digital iD. The project involved building everything from scratch and working in a monorepo. The APIs would use Jackson to serialize/deserialize JSON and since the Android code and the APIs coexisted in the same repo it made it sense to share the same model classes. This worked really well, when the API developers changed the models it automatically flowed to the Android app. It was a great if you worked on the Android app but not so good for iOS. Back then it wasn’t technically possible to share java code with iOS so the iOS devs had to duplicate these models. It was also the first time I had worked on a monorepo which has some obvious benefits but what can you do if you not using a monorepo? As it turned out the use of the monorepo on the Digital iD project at Australia Post was the exception as most of our other teams and projects use a separate repo for each microservice.

现在，让我们回到过去，回顾一下我生命中尝试做类似事情的尝试。我还将在以后解释为什么将其称为部分SDK。几年前，澳大利亚邮政开始了一项雄心勃勃的项目，以开发一种名为Digital iD的产品。该项目涉及从头开始构建所有内容并在monorepo中工作。这些API将使用Jackson来对JSON进行序列化/反序列化，并且由于Android代码和这些API在同一个存储库中共存，因此共享相同的模型类是有意义的。当API开发人员更改模型时，这确实很好，它会自动流到Android应用程序。如果您使用的是Android应用程序，那就太好了，但对于iOS来说却不是那么好。当时从技术上讲，无法与iOS共享Java代码，因此iOS开发人员必须复制这些模型。这也是我第一次从事具有明显优势的monorepo，但是如果不使用monorepo怎么办？事实证明，在澳大利亚邮政的Digital iD项目上使用monorepo是一个例外，因为我们的大多数其他团队和项目对每个微服务都使用单独的repo。

Now coming back to the present since most of our backend developers had switched or are switching to Kotlin (some teams as early as 2016) and all our Android teams have been on Kotlin for a while, this alignment in technology meant the vision of using the same API model classes was now feasible in our organisation. As a spike we decided to take a simple Spring boot API contained in its own repo and see if we share the same model classes with any JVM based client. The prospect of sharing code means less defects, faster API integration and in these troubling times the ability to work smarter and do more with less.

现在回到现在，因为我们的大多数后端开发人员已经或已经转向Kotlin(某些团队早在2016年)，而我们所有的Android团队都已经在Kotlin上工作了一段时间，这种技术上的统一意味着使用现在，在我们的组织中可以使用相同的API模型类。作为一个高峰，我们决定采用包含在其自己的存储库中的简单Spring boot API，并查看是否与任何基于JVM的客户端共享相同的模型类。共享代码的前景意味着更少的缺陷，更快的API集成，以及在这些令人不安的时刻，使人们能够更聪明地工作，事半功倍。

We decided to take a simple microservice in this case the Geofenece API which also calls another API and make its model classes shareable. These are the steps we followed;

在这种情况下，我们决定采用简单的微服务Geofenece API，该API也调用另一个API，并使其模型类可共享。这些是我们遵循的步骤；

We changed the serialization framework from Jackson to Kotlinx Serialization and converted the model classes to use @Serilizable annotation. Kotlinx Serialization also comes we a number of other annotations for using with inheritance and implementing your own serialisers. Although this model class is quite simple in reality most of our other model classes have 100s of attributes. Typos and spelling mistakes are quite common and tracking down these issues can be time consuming.
我们将序列化框架从Jackson更改为Kotlinx序列化，并将模型类转换为使用@Serilizable注释。 Kotlinx序列化还附带了许多其他注释，可用于继承和实现自己的序列化程序。尽管此模型类实际上非常简单，但我们其他大多数模型类都有100多个属性。拼写错误和拼写错误很常见，要找出这些问题可能很耗时。

2. To make the model classes shareable we modularised the API code and split it into 2 separate modules, 1 module for the models and other for the Spring Boot API.

2.为了使模型类可共享，我们对API代码进行了模块化，并将其分为2个独立的模块，一个模块用于模型，另一个模块用于Spring Boot API。

3. We also changed our CI job to publish the jar file to our Nexus repository using the Gradle release plugin.

3.我们还更改了CI作业，以使用Gradle版本插件将jar文件发布到Nexus存储库中。

./gradlew geofence-model:release

4. Then we added the shared model artefact as a dependency in our Android app for use in our code.

4.然后，我们将共享模型工件作为依赖项添加到了我们的Android应用中，供我们的代码使用。

api "au.com.auspost:geofence-model:1.1.31"

5. Finally we changed the Retrofit client to also support the Kotlinx Serilzation by adding the Kotlinx Serilzation ConvertorFactory (it’s the 7th line in the code below). By design Retrofit supports multiple converters so it’s not an all or nothing proposition which means that your Gson code can co-exist with your Kotlinx Serilzation code. That’s extremely important because it means you don’t need to change any of your existing APIs which already use Gson.

5.最后，我们通过添加Kotlinx Serilzation ConvertorFactory (在下面的代码中的第7行)，将Retrofit客户端更改为也支持Kotlinx Serilzation。根据设计，Retrofit支持多个转换器，因此它不是一个全有或全无的主张，这意味着您的Gson代码可以与您的Kotlinx Serilzation代码共存。这非常重要，因为这意味着您不需要更改任何已经使用Gson的现有API。

The end result is that now the models can be shared whether it is API to API or client to API communication with very little work. Since our microservices were already using a JSON parser making the switch to another framework wasn’t really a big deal. Kotlinx Serilzation also provides other benefits of being a faster, Kotlin safe and more light weight than other serialization frameworks such as Gson or Jackson. Also, the fact that you now have a potential sharable artefact that could be used on multiple platforms is a win-win scenario. As a consumer of an API service would you prefer rich model classes with types, nullability and metadata or just a plain JSON document?

最终结果是，现在只需很少的工作即可共享模型，无论是API到API还是客户端到API通讯。由于我们的微服务已经在使用JSON解析器，因此切换到另一个框架并不是什么大问题。 Kotlinx Serilzation还具有比其他序列化框架(例如Gson或Jackson)更快，Kotlin安全且重量轻的其他优点。此外，您现在拥有可以在多个平台上使用的潜在共享物品的事实是双赢的。作为API服务的使用者，您希望使用具有类型，可为空性和元数据的富模型类，还是仅使用普通的JSON文档？

Although our spike didn’t include generating code for iOS, our other spikes have shown this is indeed possible. At the moment we are looking for a good solution for building iOS code in the cloud. We are getting pretty close to the dream of having a partial SDK for our all clients but we aren’t there yet. It’s only a partial SDK as it doesn’t provide exceptions, the URL paths or operations like PUT or GET, however if you use Retrofit it’s really easy and fast to add this stuff. In our teams we find that coding the models is the most tedious and error prone part. Our approach to adopting KMP is to leverage as much of our existing code and frameworks as possible, although we could move to Ktor to provide a complete API SDK we feel that this would introduce too much change.

尽管我们的峰值未包括为iOS生成代码，但其他峰值已表明这确实是可能的。目前，我们正在寻找在云中构建iOS代码的良好解决方案。我们已经接近为所有客户提供部分SDK的梦想，但我们还没有实现。它只是部分SDK，因为它不提供异常，URL路径或PUT或GET之类的操作，但是，如果您使用Retrofit，添加这些内容确实非常容易且快速。在我们的团队中，我们发现对模型进行编码是最乏味且容易出错的部分。我们采用KMP的方法是尽可能地利用我们现有的代码和框架，尽管我们可以选择使用Ktor来提供完整的API SDK，但我们认为这会带来太多变化。

If you liked this article, also check out this one — https://medium.com/@markchristopherng/kotlin-the-next-enterprise-language-547d2dec2a66

如果您喜欢这篇文章，也请查看这篇文章— https://medium.com/@markchristopherng/kotlin-the-next-enterprise-language-547d2dec2a66

Btw, thanks to Karl Maul for helping with the spike and proof reading the article.

顺便说一句，多亏了卡尔·莫尔(Karl Maul)为阅读本文提供帮助和证明。