在使用 Swift on Server 之前，我最熟悉的 Web Framework 是 Ruby on Rails，除此之外，我也使用过 Python，NodeJS，Elixir 和 Go 来编写后端，但给捧读编写后端服务的时候，我权衡再三，最终选择了 Swift on Server.
本章将分享当时我为何做了这个决定，以及这个决定在随后的三年为何被验证是正确的选择，如果你和我的情况类似，那么相信会有所收获。
捧读——一款基于机器学习技术的日语语法分析 App
捧读在 2019 年的研发之初，是作为一款单机产品设计的，初衷是希望即使我不在了，这款产品也依旧可以很好的运作，让用户实现真的一次购买，永久使用。
设计为单机产品主要起因于我两个想法
但随着时间的推移，捧读的机器学习模型更新给我带来了麻烦。
在单机的情况下，模型更新完全依赖于用户是否更新了 App，因此，我无法保证每个用户都能及时使用上最新的模型，获得最好的体验，除此之外，用户会逐渐积累很多学习数据，如果不提供云同步功能，用户难以跨设备使用，更是容易产生丢失数据的问题。
因此，为了解决「用户体验」和「单机」之间的冲突，在 2021 年的时候，我决定给捧读设计一个后端。
在调研技术方案前，我们先来看下捧读服务端有哪些需求
以 Ruby on Rails 来说，这是一个我从 2013 年就开始使用的 Web 框架，也一直是它的拥趸，那么，先来看一下它的优劣
优点：
缺点：
反观 Swift on Server，它的优缺点有哪些呢？
优点：
缺点：
除此之外，Swift 对我来说还有三个加分项
因此，Swift on Server 对我来说，只要扬长避短，克服这些缺点，就是一个完美的选择。
就像脚本语言借用其他语言来补全自己的短板一样，Swift 也同样可以借助其他语言的生态来补全自己的短板，在这个 Cloud Native 的时代，借助微服务和 Serverless 的帮助，我们可以很轻易的解决这些问题。
以 Azure 为例，Azure TTS 并没有提供 Swift 的服务端 SDK，但可以很容易的找到其他语言的，比如 Python 和 NodeJS.
我的解决方案是用 JS 把和 Azure TTS 打交道的功能，部署到 AWS 的 Lambda 上，当 Server App 需要和 TTS 打交道的时候，就用 HTTP 请求这个 Lambda Function.
这个方案的优点如下
我们很容易面临一个这样的问题，我喜欢 Swift，他可能喜欢 Rust，其他人则可能喜欢 Go 或其他语言。
当我选择了 Swift on Server 的时候，是否和其他人的世界就无缘了呢？
当然不是！通过一个精巧且合理设计的微服务架构，你可以很轻松的在不同的业务模块里，使用完全不同的语言和技术，相较于使用一门语言实现一个大单体应用，这样带来的直接好处有两点
从 2021 年服务器上线至今，已经高效，稳定的运行了 3 年，在这期间，业务从仅有的用户系统和语法分析，拓展到了支付系统，账单系统，以及后来的生词本和学习系统，在未来，我也会继续使用 Swift on Server 完成其他的产品需求。
之所以开启这个系列，是希望将我使用 Swift on Server 的经验系统的分享出来，让更多的人可以从中受益。
诚然，Swift on Server 不会是适合每个人的方案，因此我也列了一个画像，如果你符合这些条件，那么请持续关注这个系列的文章。
符合下列任何一条皆可
本系列文章的会以一个 Micro Blog Server 为示例，和你一起畅游 Swift on Server 的世界，这个系列主要面向对服务器开发的初学者，因此除了功能的实现外，会写很多概念相关的内容。
总体来说，话题会涉及到以下方面
我会利用闲暇的时间，更新这个系列，希望能够完成每 1 - 2 周一更，欢迎持续关注！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。