适用于希望在2019年超越自我的Node.js开发人员的19个想法

该材料的作者(我们发表了译文)收集了19个想法,这些想法对于希望在2019年提高专业水平的Node.js开发人员可能有用。 JavaScript的世界很大,因此精通本文将要讨论的所有内容都是不现实的。 不可能有人完美地拥有这一切。 但是,此评论中的某些内容很可能对您有用。



1.考虑打字。 注意TypeScript


事实证明 ,使用JavaScript中的键入方法进行JavaScript编程会导致劳动生产率下降和出现错误。 这并不意味着您应该努力确保所有代码都是强类型的。 相反,我们正在谈论的事实是,在使用JavaScript开发时,选择一种使用类型并坚持使用的方法会很好。 除其他事项外,此类方法的区别在于与施加在代码上的数据类型相关的限制级别。 例如,它可能非常简单,例如使用jsonschema (或joi )包组织检查。 如果您认为需要更严格的类型控制,可以考虑在常规JS代码中使用类型注释(此处来自Facebook的流程将对您有所帮助)。 而且,如果您准备编写几乎完全键入的代码,请注意TypeScript

应该指出的是,在2018年TypeScript受到了广泛的欢迎,此外,还有一种感觉,它具有在Node.js中牢固建立自己的所有先决条件。 如果您正在认真研究TypeScript,则应问自己是否只是在考虑键入或该语言的其他功能。 这里的要点是,使用诸如接口和抽象类之类的东西意味着您将发现自己处于一个主要考虑打字的环境中,而您几乎不会参与其中。

2.注意短绒的能力


这些天的短毛绒被认为是理所当然的。 经过简单的设置,您可以使用一个工具来帮助您找到代码中的错误。 线性化代码主要是指控制其设计(例如是否存在分号)的日子已经一去不复返了。 现在,lint可以识别出严重的问题,例如无法正确处理的错误,无法解决的承诺以及其他任何人都不会有意识地将其包含在其代码中的类似问题。 因此,如果您还没有使用Linter,现在是时候做它了,而不必忘记它的周到配置。 例如,这里是ESLint的插件eslint-plugin-chai-expect ,它可以检测错误组成的测试。 这是eslint-plugin-promise插件 ,用于检测未解决的承诺(带有此类承诺的代码,出于明显的原因,只是停止)。 使用eslint-plugin-security插件,可以在代码中找到不安全的正则表达式,攻击者可以使用它们执行DOS攻击。

3.通过从Java领域学习并从Ruby领域中学到很多东西,加深对软件项目体系结构的了解


Node.js的生态系统很少提出信息系统的体系结构和设计主题。 因此,每个人都在谈论微服务,但很少有人谈论其内部结构。 因此,大多数Node.js应用程序都是实现MVC概念和Ruby世界中其他可疑模式的示例。 那有什么不好的呢? 例如,创建MVC模板是为了简化数据处理,但是此模板不适用于设计应用程序的可靠服务器部分。 例如,鲍勃·马丁(Bob Martin) ,MVC是一种用于将数据传递给用户的机制,而不是应用程序体系结构。 是否可以仅使用ControllerModel两个类来描述微服务应用程序的业务逻辑,其操作规则,数据访问的功能,与其他微服务的交互?
应该注意的是,我绝对不想在这里推荐在Node.js中使用Java / Spring模板(毕竟,我们切换到Node.js来开发服务器程序不是偶然的吗?)。 我建议您仅借鉴一些想法,这些想法一方面可以对应用程序体系结构产生有益的影响,另一方面也不会导致它们的过度复杂性。

对于那些关心Node.js项目的体系结构的人,这是一些准则:

  • 阅读有关Node.js应用程序体系结构的本文的第一部分。
  • 尽量不要将应用程序业务逻辑与Express对象混合使用,请阅读有关域驱动设计 (DDD)原理和六角形体系结构的信息
  • Active Record模式的使用在使用Mongoose和Sequelize的开发人员中非常流行,很容易导致出现难以测试的重载对象。 考虑使用Data Mapper模式而不是Active Record模式。
  • 查看这个精心制作的模板Node.js项目的代码, 项目具有实现DDD原理的高质量体系结构。

4.考虑使用异步代码时如何使用新的Node.js-API async_hooks


JavaScript中使用的单线程代码执行模型有一个严重的缺点-异步操作(例如请求)会丢失上下文。 它不会在查询生命周期中保存,因为异步操作涉及其执行。 为什么这样不好? 例如,开发人员经常寻求在日记帐分录中包含唯一的查询标识符,当分析此类记录时,它允许人们标识与同一查询相关的那些标识符。 今天,在2018年,这并非易事。 明年,我们正在等待着新的事物,即我们正在谈论的异步钩子async_hooks API。 这并不是说这是一个全新的机会,而是要尽快离开实验机制。 简而言之,异步挂钩允许开发人员在异步操作的生命周期中的某些时候执行本机代码。 考虑到这一点,您可以协调异步代码执行的操作并维护上下文。 此功能为开发软件包奠定了基础,这些软件包会将Node.js提升到跟踪异步操作和使用上下文的新水平。

例如,使用cls-hooked软件包可以在异步操作的整个生命周期内组织变量和上下文的使用。 jaeger-client软件包使您可以可视化通过系统(甚至通过微服务和服务器)传递请求的过程(此处实现了Javascript OpenTracing API 1.0标准)。

这是查找有关使用async_hooks API的更多信息材料。

5.了解最新的“无服务器”技术,这些技术已经为重大项目准备就绪,并且能够杀死Kubernetes


在这里,我们使用FaaS(功能即服务,功能即服务)和“无服务器技术”的概念作为同义词,尽管它们的含义并不相同。 特别是,下面我们将讨论云FaaS服务。

最初,FaaS技术旨在开发微任务,而不是创建成熟的“微服务”应用程序。 FaaS平台的日益普及导致对云服务提供商的兴趣增加,FaaS平台获得了新功能。 结果,尽管这是出乎意料的,但有一种感觉,即2019年FaaS平台可以成为严肃项目的基础。 这些平台能否与Kubernetes竞争并用于托管大型应用程序? 有人认为无服务器计算和FaaS技术是全新的东西,但实际上,每个云应用程序的创建者都必须在2019年在这三种技术之间做出选择。 从字面上看,此选择显示在云服务提供商的网站上。 即,我们正在谈论选择以下三个选项之一:

  1. 普通云服务器(例如RUVDS中的VDS
  2. Kubernetes
  3. FaaS

因此,在我们这个时代,能够比较Kubernetes和FaaS的功能并预测选择特定技术的后果非常重要。

6.检验将很快成为标准的JavaScript创新。


我不能称自己为寻找和使用该语言的最新功能的支持者,因为有时使用它们会损害代码的简单性和易懂性。 但是,有时会出现真正有价值的JavaScript功能(例如两年前的async / await结构),因此查看TC39报价清单和node.green资源很有用,以便提前了解可能适合您的新功能。 这是我在这里发现的有趣之处:

  • 类别字段现在处于批准的第3(最后)阶段,可以在2019年进入标准。
  • BigInt数据类型也要经过对帐的最后阶段。 使用此类数字可以帮助组织与微服务或任何使用大量数字的系统的交互。
  • 异步迭代器finally()承诺方法已经被接受。 如果您尚未关注它们,请阅读它们。

7.掌握至少一种用于创建API的技术。 注意GraphQL


REST-API是解决特定类别任务的好工具。 即,我们正在谈论管理查询和修改数据库中的记录。 您的系统是否专注于处理财务数据? 为了确保其运行,可能有必要遵守最严格的限制并使用精心开发的数据模型,该模型不允许歧义。 REST技术在这种情况下适合您,但是在其他非常常见的情况下,例如在执行相同请求可能导致接收到不同数据集的情况下,REST技术无法很好地展现自己。 当使用某种API时,需要传输尽可能少的数据时,连接速度低的情况下的工作也是如此。 这样的情况包括计算机之间的连接,其中高速通信才是最重要的。 在这种情况下,切换到新的东西值得吗? 不,不值得。 最好在已使用的内容中添加一些新内容。 API不是应用程序体系结构。 这只是对应用程序的访问点,这意味着使用不同工具创建的API可以共存。 即使它们都构建在单个Web框架(如Express)之上。

学习什么技术? 在当前情况下,可能值得投注的是GraphQL技术,该技术正变得越来越流行。 这项技术的生态系统已经大大成熟,它可以为一些非常流行的数据场景提供服务-例如动态搜索以及与分层数据源的交互。 另一方面,gRPC技术仍然是一种高度专业化的解决方案,非常适合在数据交换期间希望传输尽可能少的服务信息的情况下服务器之间的通信(例如,我们正在讨论基于“发布者-订阅者”,或有关使用消息和消息队列的对象)。 这是有关此主题的一些有用的文章:

  • REST,GraphQL和gRPC的比较
  • 基于Node.js和Express的GraphQL服务器开发
  • 11分钟的 YouTube 视频 ,介绍GraphQL的基本知识

8.使用单元测试和集成测试吗? 看看全新的测试技术。


您是否已经熟悉测试金字塔,单元测试,集成测试和端到端测试? 如果是这样-太好了。 所有这些都是成功的测试策略的基础。 但是,应该指出的是,在过去的10年中,软件开发领域发生了非常严重的变化,测试模型保持不变,这使我们对如何测试微服务,富Internet应用程序,无服务器系统提出了疑问。 一些现代的测试方法可以补充传统技术,甚至可以替代传统技术,从而改善测试策略和结果。 这是您可以阅读并看到的内容:

  • 基于“消费者驱动的合同”模式构建的测试系统有助于防止微服务或客户端使用的服务器API出现故障。
  • 使用快照的测试不仅可以在前端使用,而且可以在服务器项目中使用。
  • 组件测试是一种测试微服务的平衡方法。
  • 这是有关测试Node.js项目的现代方法视频。

9.使您的应用程序监视系统符合SRE / DevOps最佳实践


在2019年,即使是中型应用程序也可能包含数十个组件。 为了确保此类基础结构的平稳运行,必须对其进行仔细的监视。 尽管上述内容很明显,但是大多数开发人员仍然不认为研究和使用这些建议来监视应用程序以及创建有关问题的警报系统很重要,这些问题可以由负责Web项目可靠性的专家提供给他们。 例如,开发人员通常专注于系统性能的内部指标,例如处理器速度或RAM,而不是担心直接影响最终用户的指标。 特别是,我们正在谈论错误和延迟的频率。 这称为 “基于症状的监视”。 这种面向用户的指标有时被称为“黄金信号”,您可能要引入监控系统,因此决定从引入此类指标开始。 以下是相关材料:


10.通过从攻击者的角度查看项目,以及学习如何进行攻击和黑客工具,提高项目的安全性


如果您无法像想要攻击您的系统的人那样思考,则意味着您无法像该系统的防御者那样思考。 在2019年,您既不应将保护项目的任务转移给第三方,也不应仅依靠静态安全分析器。 如今,攻击种类繁多(此领域的最新趋势是对开发基础架构和npm的攻击 )。 同时,应用程序变化非常非常快-昨天该项目被认为受到良好保护,明天它们可以添加多个新的AWS服务,多种新的数据库类型和新的IAM角色。 同时,分析项目的安全性不会很快。 结果是开发人员给自己的项目带来了最大的安全风险。 解决这个问题的方法是他们的培训。 这意味着每个Web项目开发人员都需要将安全性规则的实现几乎自动化,并且无论他做什么,都必须牢记安全性。

在您决定朝这个方向发展之后,事实证明,在执行任何工作时考虑到安全性并不那么令人恐惧。 说,熟悉攻击的常用方法和工具后,绘制应用程序体系结构图并考虑如何攻击它。 随着时间的流逝,您甚至没有给自己报告,您将开始考虑安全性问题,做出每个体系结构决策并在编辑器中输入每行新代码。 以下是一些管理安全性问题的想法:

  • 尝试OWASP ZAP-一种用于研究系统和黑客行为的多功能工具,即使是初学者也可以使用它来学习应用程序安全级别。
  • 请查看 Node.js安全建议列表,以获取两个以上的攻击思路和JavaScript代码示例。
  • 安排每月一次的威胁分析会议,项目团队将在该会议上研究其体系结构并对其进行攻击。 如果您觉得这样的想法很无聊-您可以将此类会议进行游戏化。 说,发现脆弱性的人可以得到某种奖励。 例如,您还可以将这样一个会议的参与者分成两个团队,并安排他们之间的竞争来发现漏洞。

11.设计并实施npm软件包更新策略。 2018年显示更新它们时仓促是危险的


通常,开发团队会遵循两种“策略”之一来更新npm软件包。 他们要么在新版本发布后尽快更新它们,有时甚至自动执行此过程,要么根本没有软件包更新策略。 使用这种方法,软件包会不定期地更新,并且在开始此过程时,它们会受到突然的想法的引导:“我们今天应该更新吗?” 尽管这些方法中的第一种看上去比第二种更好,但出乎意料的是,2018年比第二种方法带来的风险更高。 社区在几十天之内发现了问题,例如固定流软件包所发生的问题,那些不急于更新的人是安全的。

考虑正式制定更新项目所依赖的软件包的策略;考虑在此过程中使用自动化工具。 在拒绝更新和经常更新软件包之间找到中间立场。 在这里, npq程序可以为您提供帮助,该程序在安装过程中检查软件包并提供建议。 您可以看看greenkeeper等商业项目。 这种解决方案的缺点是,它们无法将安装推迟到完全确定某个软件包是安全的那一刻。

12.仔细研究项目的分阶段部署


也许在2019年,您会认为使用分阶段方案在生产中部署项目是合理的,而不是立即将开发过程中以前的所有内容立即发送到战斗服务器。 此过程称为“ canary部署”,与同时部署新代码相比,它提供了更高级别的项目保护。 它通常区分以下三个阶段:

  1. 部署方式 新代码将部署在新的隔离生产环境中(在新的Kubernetes服务上,在新的虚拟服务器上)。 在此阶段,该代码尚未提供任何服务,因此,代码失败不会造成伤害。
  2. 测试。 现在,由于代码已在生产环境中部署,因此有几位专家可以在尽可能接近真实条件的条件下使用新代码。
  3. 放行 在测试表明新代码的可操作性之后,正逐渐使它获得越来越多的用户的访问,并且在事实证明它足够可靠地工作之后,其旧版本逐渐被淘汰。

这里要说明的重要一点是,在2019年进行全面的金丝雀部署仍然是非常昂贵的乐趣。 事实是,这需要协调项目的基础架构元素的工作,例如路由和监视。 因此,如果要应用类似的技术,则应从简单的,部分手动的金丝雀部署开始。 特别地,这包括以下事实:在成功完成首次测试之后,考虑到监视指标,将带有新版本软件的服务器手动添加到系统中。 在此处阅读更多关于金丝雀的信息 。 如果要自动化执行此类发布的过程,请注意Spinnaker平台。

13.查看征服世界的Kubernetes技术。


Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. — . K8S — , :


, , Kubernetes, .

14. -,


- — . , .

15. , , ,


, — . , . . , (, tensorflow.js brain.js , , ).

16.


, . , , . , — .

17. Linux, —


Linux- , , . — , ( — ), Docker, . , , , , , . , Linux.

18. , Node.js


( Node.js): « . , ». , , ( ). , Node.js, , V8 libuv. , 2019 — , Node.js, , , libuv. , , , Node.js - , .

, . , npm- C/C++. Node.js. Node.js RUVDS.

19. ,


, , . , , , , , . , , , , . JavaScript-, . , JavaScript, . , , TypeScript . flow , , . , - flow, , , , « , ». ? , , « ». , - . , , , — . . , - , , , . , . , 2019 , — .

. , . — , , , , , , . , , , , , .

总结


19 , Node.js-, - , 2019 . , - , .

亲爱的读者们! Node.js- 2019 ?



Source: https://habr.com/ru/post/zh-CN434114/


All Articles