为什么我们在无服务器上使用 Typescript 而不是Java？

由于这与我们的业务应用程序有关，因此我不会详细记录项目中发生的所有事情，并且会操纵某些背景。但是，我相信所有与技术相关的部分都是事实，我试图尽可能精确地进行写作。我希望本文将帮助您获得一些知识，并通过无服务器转移解决您的问题。

介绍

无服务器是最现代、最受关注的软件体系结构之一，近来越来越多的开发人员开始在自己的应用程序或服务中使用它。

我现在也非常喜欢它，我再也想不回自我管理服务器模型了。

基本上，我相信，如果您的应用程序是为扩展和分发而设计的，那么我们依赖服务器应用程序的大多数功能都将丢失。

因此，这些天来，如果有人询问Web服务的体系结构或设计，我总是鼓励无服务器。

顺便说一句，由于它是与传统开发方法完全不同的方法，因此Serverless要求我们更新知识并查看我们一直在使用的技术堆栈。

我们还应该使用哪种语言，这也是我们需要审查的内容之一。

最后，我们开始使用* Typescript，并且已经使用它超过一年半了。

而且，尽管只是个人意见，但它比我们预期的要好得多。

因此，我想写一下旧技术堆栈有什么问题，以及将其切换为Typescript后有什么好处。

为什么我们需要放弃Java

在谈论选择打字稿的原因之前。我想解释一下为什么我们放弃了使用最出色的语言之一Java的先前技术堆栈的原因。

--------------
注意

首先，我是Java爱好者，我也是Java语言的母语。（没有泛型功能的Java 4或5。）

我研究了JVM，并从中获得了很多启发。我想这是上帝造的。

因此，在这里我根本不鄙视或侮辱Java。

关于Java的任何评论或投诉都不受欢迎，只是它目前在无服务器环境下无法正常工作。

---------------

好的，抱歉，让我们继续。

长期以来，我们一直将Java用作服务的主要语言，我们实际上知道Java具有许多优势，例如

• 无平台
• 精心设计的JIT编译
• 优秀的GC
• 结构良好的语法
• 类型强
• 最近支持函数式编程
• 有很多图书馆
• 可信赖的社区。（不是Oracle，而是开发人员社区）

等。

我们真的很感激并非常依赖他们。

但是，当我们使用无服务器的代码测试代码时，我们发现Java不太好，无法在FaaS服务（例如AWS Lambda）上运行。

原因如下。

• 启动JVM的开销不可忽略。
• 此外，我们的主要框架Spring在启动容器上花费了更多时间。
• 最终的源代码包相对较大。（有时超过100MB）
• 功能数量增加时，不使用Web框架就很难代理请求
• G1GC或JIT编译无法正常工作，因为容器很快停止
• 无法享受免费平台的好处，因为它始终在带有Amazon Linux映像的EC2上运行。（不是缺点，只是减少了使用Java的原因）

上面列出的所有问题都很烦人，但是在这里我想解释上面最麻烦的问题之一。

Lambda的冷启动太麻烦了

我们最初面临的最麻烦的事情就是冷启动的开销。是的，我想大多数无服务器开发人员可能都遇到过同样的问题。

我们使用AWS Lambda进行计算，并且每当用户发出请求时，AWS Lambda都会启动容器。

一旦启动，它会重用同一个容器实例一段时间，但是在初始启动时，它需要启动Java Runtime环境以及所有必要的Web容器或框架环境。

此外，即使您的应用程序已准备好线程池中的数百个请求线程，一个容器也只能用于处理单个请求，并且不能同时用于多个请求。这意味着当多个用户同时将请求发送到终端节点时，AWS Lambda需要启动另一个Lambda容器来处理其他请求。

实际上这很麻烦，因为通常我们无法估计并发请求的数量，并且热备用机制不起作用。（即使我们以某种方式做到了。）最终，它将迫使用户等待几秒钟来打开页面或处理请求，并且我们确信这肯定会降低用户体验。

在看到冷启动令人讨厌之后，尽管在过去几年中我们已经编写了很多代码，但最终，我们放弃了所有代码，转而使用另一种语言。

为什么我们选择打字稿

实际上，这有点可耻，我们决定从很早的阶段开始使用Typescript，而无需深入思考或与其他语言进行比较。

但是，老实说，在这种情况下，除了Typescript之外，我们别无选择地使用Lambda支持的其他语言。

首先，我们别无选择地使用动态类型语言。服务和代码应由各种熟练的开发人员长时间运行，支持，维护和扩展。因此，我们不想在服务器端使用动态类型的语言。

因此，Python和Ruby都不可行。

C＃和Go具有与我们（和其他团队）正在使用的语言完全不同的特征，其他新手可能需要一些时间才能赶上。

当然，我们大家都知道，最近这两种语言，尤其是Golang由于其性质而逐渐赢得了份额。

但是，更改拱门是一个太过紧迫的任务，我们也没有太多时间自己去追赶它。因此，尽管这两种语言让我们着迷，但我们还是放弃了使用这些语言。

使用打字稿的好处

所以最后，我们决定使用Typescript。

Typescript的好处如下。

• 类型强
• 小得多的包装
• 超快速启动开销
• 能够重用javascript和Java的知识
• 节点库和社区很棒
• 即使与javascript相比也适用于函数式编程
• 能够使用类和接口编写结构良好的代码

众所周知，静态类型对于像B2B这样长期运行的项目而言是一个重要因素，因此我在这里不做过多介绍。在这里，我想解释一下Typescript如何很好地工作。借助打字稿的其他功能，该打字稿确实比我们预期的要好得多。

使用小包装启动的开销更少

在无服务器环境中，这可能是从Java切换到Typescript的最重要因素。（其他好处几乎与使用打字稿本身的好处有关）

如前一部分所述，Java有开销来启动框架的JVM和DI / Web容器。

此外，作为Java的本质，它在AWS Lambda中具有以下弱点。

Typescript没有这些缺点，它解决了我们的担忧。

多线程及其生态系统

多线程是Java的强大功能，它确实有助于我们实现高性能代码。

甚至JVM本身也将其用于垃圾回收，以提供出色的运行时性能。

（请参阅G1GC或JIT编译）

但是，您会发现准备容器中使用的所有线程需要100毫秒到几秒钟的时间。

对于在EC2上运行的客户端-服务器这样的常规体系结构，它足够小且可忽略，但对于在Laada之类的FaaS上运行的无服务器应用程序来说，它完全不可忽略。

Typescript基于nodejs，默认情况下仅支持单线程。（异步或同步仅由调用堆栈而不是线程控制），

因此，启动它的时间比具有现代框架的Java短。

大包装档案

在无服务器环境中，通常首选小包装。

启动lambda容器后，该容器会从S3中的AWS托管源存储桶下载源代码。

通常，下载S3的时间很小，但如果是100MB或200MB，则不可忽略。

使用nodejs，与Java相比，程序包的代码大小可能会相对较小。

老实说，我不太清楚为什么会这样，但是可能是由于以下原因。（如果您了解更多信息，请在评论中教我。）

• Java框架通常是综合性的，可以包含许多相关的库来覆盖所有内容，但是javascript框架或库更像是现场的，并且包含的​​不必要的文件太多。
• Javascript可以在一个文件中编写多个模块或函数，并且可以轻松地对其进行维护，但是Java需要设计具有多个文件的类和接口来编写可维护且结构良好的代码。

实际上，使用Java时，打包的jar 最大为200MB。

但是，通过使用nodejs，它最终可以减少到35MB以上。

部分原因是我们试图在上一个架构中重用Spring Tech堆栈。

但是，即使删除了不必要的依赖性和优化之后，用于一个功能的软件包仍需要50MB。

能够使用javascript的知识和生态系统

当我们一直在研究Web服务时，我们对javascript和nodejs有一些了解。

在Jquery时代到像React或Vue这样的现代javascript时代，我们已经了解了它的优缺点，并获得了一些技巧来用javascript编写良好的代码。

Typescript是一种种类繁多的javascript语言，最后将被翻译成javascript。

因此，许多习语或语法都是从javascript扩展而来的，我们无需进行大量准备就可以轻松开始编写代码。

此外，大多数有用的库都为打字稿提供了其类型定义，因此我们也能够享受到nodejs生态系统的好处。

与函数式编程范例很好地配合

这些天，当我们谈论技术趋势时，函数式编程是一个非常重要的范例。

它可以让您根据其性质来编写简单，可测试，不太危险和稳定的代码。

AWS Lambda始终要求我们从代码中摆脱状态。函数式编程要求我们将副作用或状态与函数隔离开来，而这种想法肯定会使我们的Lambda代码更具可维护性。

基本上，正如John Resig在“ JavaScript忍者的秘密”中所讲的那样，JavaScript从一开始就支持函数式编程。

它将Function视为第一类对象，jquery也应该以功能方式编写。

但是，普通的javascript是动态类型，有时会给编写好的函数带来一些困难。

我们可以用单个基本类型表示的函数种类非常有限，并且使用Object类型作为参数/返回值有时会很麻烦。

使用typescript，我们可以指定参数的类型或返回值。

此外，以下功能使您可以更安全，简单和更具表现力地编写代码。

• 类型：可让您区分常见类型及其方面，例如字符串和UserId或Promise和Either。
• 接口/类：使您可以将参数/返回类型的集合组织成适合于服务中的上下文。
• 枚举：我猜没有任何必要的解释。
• 只读：使您的对象不可变。
• 泛型：使您的功能接口更具表现力。

Typescript在函数式编程方面具有更多优势，但在此不一一列举。（部分原因是它是JavaScript而不是Typescript的优势。）

请尝试一下，享受发现的乐趣。

能够重用我们在Java中使用的最佳实践

看完打字稿的教程后，您会发现它与Java或Scala十分相似。

在某种程度上，我们已经接受了如何通过Java编写良好代码的培训，这是他们经过的漫长旅程。

我们知道我们应该如何设计类和接口，如何有效使用枚举，如何使流API在Java中可维护，这不是我们可以立即放弃的事情。

由于Typescript和Java的相似性，我们可以轻松地将以前的做法应用于新的代码库。

Typescript支持接口，类，访问修饰符和只读属性（与Java中的final属性等效），它实际上帮助我们重用了我们在Java中学习到的最佳实践，包括面向对象的编程实践和设计模式。（我相信FP和OOP不是矛盾的，可以在同一项目中使用。）

如果我们选择的是Python还是Ruby，也许我们需要很长时间才能找到如何将这些实践应用到新语言中的努力，

（实际上，当然，我知道这很有趣，但是暂时没有急于更换拱门）

当然，我们没有在现有的Java类中进行逻辑的复制粘贴。

但是，即使我们从头开始为它们重新写入了80％的内容，也并不需要花费很多时间来再次以可接受的质量进行写入。

结论

我们在Typescript的旅程中仍然是新手，需要学习很多东西，但是已经发现了很多好处，我们真的很享受。

如果现在问，可能是使用Golang的一种选择，将Micronauts与GraalVM一起使用也是一种选择，或者也许我们可以选择更多选择。但是，到目前为止，我对打字稿真的很满意，并且相信它是我们可以在无服务器中选择的最佳选择之一。

当然，使用Typescript和无服务器已经遇到了一些困难，例如如何用相对较慢的语言进行批处理，如何进行并行计算或分布式处理，如何进行工作流，如何克服API Gateway的超时或如何处理。确保数据一致性。

但是，所有这些事情对于我们（极客）来说都是最有趣的事情。

实际上，我们已经找到并克服了一些实践。我会在不久的将来写它。

如果您在无服务器上使用Java挣扎并且对无服务器失去希望，我强烈建议您考虑使用Typescript。我可以保证它将比您期望的更好。

感谢您阅读这篇长文章。很高兴收到您的评论或联系（如有）。

from：https://dev.to//csohei/why-we-used-typescript-instead-of-java-on-serverless-39e2