[译] Express 在生产环境下的最佳实践-性能和可靠性

前言

这将是一个分为两部分,内容是关于在生产环境下,跑Express应用的最佳实践。第一部分会关注安全性,第二部分则会关注性能和可靠性。当你读这篇文章时,会假设你已经对Node.js和web开发有所了解,并且对生产环境有了概念。

关于第一部分,请参阅Express在生产环境下的最佳实践 - 安全性

概览

正如第一部分所说,生产环境是供你的最终用户们所使用的,而开发环境则是供你开发和测试代码所用。故对于和两个环境的要求,是非常不同的。例如,在开发环境下,你不必考虑伸缩性和可靠性还有性能的问题,但这些在生产环境下都非常重要。

接下来,我们会将此文分为两大部分:

  • 需要对代码做的事,即开发部分。
  • 需要对环境做的事,即运维部分,

[译] Express 应用结构的最佳实践

前言

NodeExpress并不严格要求它的应用的文件结构。你可以以任意的结构来阻止你的web应用。这对于小应用来说,通常是不错的,十分易于学习和实验。

但是,当你的应用在体积和复杂性上都变得越来越高时,情况就变得复杂了。你的代码可能会变得凌乱。当你的团队人数增加时,向在同一个代码库内写代码变得愈发困难,每次合并代码时都可能会出现各种各样的冲突。为应用增加新的特性和处理新的情况可能都会改变文件的结构。

一个好的文件结构,应该是每一个不同的文件或文件夹,都分别负责处理不同的任务。这样,在添加新特性时才会变得不会有冲突。

[译]Express在生产环境下的最佳实践-安全性

前言

这将是一个分为两部分,内容是关于在生产环境下,跑Express应用的最佳实践。第一部分会关注安全性,第二部分最会关注性能和可靠性。当你读这篇文章时,假设你已经对Node.js和web开发有所了解,并且对生产环境有了概念。

概览

生产环境,指的是软件生命循环中的某个阶段。当一个应用或API已经被它的终端用户所使用时,它便处在了生产环境。相反的,在开发环境下,你任然在不断得修改和测试代码,应用也不能被外部所访问。

开发环境和生产环境经常有很大的配置上的和要求上的不同。一些在开发环境下可以使用的东西,在生产环境下,它们不一定是能够被接受的。例如,在开发环境下,我们需要详细的错误日志信息来帮助我们debug,而在生产环境下,这则会带来安全隐患。又比如,在开发环境下,你不必考虑可伸缩性和可靠性还有性能的问题,但这些在生产环境下都非常重要。

以下是将Express应用部署于生产环境中的一些安全性方面的最佳实践。

[译] 初窥 Express 5

前言

Express 5.0 仍处于alpha版中,但是我们还是想先来初窥一下新的express版本中将会有哪些改变,以及如何将你的应用从Express 4 迁移至 Express 5。

Express 5 与Express 4 的区别,并有像之前从Express 3 更新至 Express 4 时的那样非常巨大。但是,仍然还是有几个API有了颠覆性的变化。这意味着你的Express 4 应用在更新至Express 5 之后,将有可能不能运行。

安装

想要使用alpha版的Express 5 ,你只需在你应用的根目录下运行命令:

1
$ npm install express@5.0.0-alpha.2 --save

完成了以上步骤之后,你便可以运行你项目中的自动化测试,来看看有哪些代码运行失败了,然后根据下文列出的Express 5 的更新清单,来修复它们。(你的代码应该是有写测试的吧。。)接着,根据测试的错误信息,来实际运行你的应用,看看到底是发生了什么错误。这些错误应该都是使用了Express 5不再支持的属性和方法所导致的。

[译] Node.js 安全清单

前言

安全性,总是一个不可忽视的问题。许多人都承认这点,但是却很少有人真的认真地对待它。所以我们列出了这个清单,让你在将你的应用部署到生产环境来给千万用户使用之前,做一个安全检查。

以下列出的安全项,大多都具有普适性,适用于除了Node.js外的各种语言和框架。但是,其中也包含一些用Node.js写的小工具。

配置管理

安全性相关的HTTP头

以下是一些安全性相关的HTTP头,你的站点应该设置它们:

  • Strict-Transport-Security:强制使用安全连接(SSL/TLS之上的HTTPS)来连接到服务器。
  • X-Frame-Options:提供对于“点击劫持”的保护。
  • X-XSS-Protection:开启大多现代浏览器内建的对于跨站脚本攻击(XSS)的过滤功能。
  • X-Content-Type-Options: 防止浏览器使用MIME-sniffing来确定响应的类型,转而使用明确的content-type来确定。
  • Content-Security-Policy:防止受到跨站脚本攻击以及其他跨站注入攻击。

[译] JavaScript ES6 箭头函数指南

前言

胖箭头函数(Fat arrow functions),又称箭头函数,是一个来自ECMAScript 2015(又称ES6)的全新特性。有传闻说,箭头函数的语法=>,是受到了CoffeeScript的影响,并且它与CoffeeScript中的=>语法一样,共享this上下文。

箭头函数的产生,主要由两个目的:更简洁的语法和与父作用域共享关键字this。接下来,让我们来看几个详细的例子。

新的函数语法

传统的JavaScript函数语法并没有提供任何的灵活性,每一次你需要定义一个函数时,你都必须输入function () {}CoffeeScript如今之所以那么火,有一个不可忽略的原因就是它有更简洁的函数语法。更简洁的函数语法在有大量回调函数的场景下好处特别明显,让我们从一个Promise链的例子看起:

1
2
3
4
5
6
7
function getVerifiedToken(selector) {
return getUsers(selector)
.then(function (users) { return users[0]; })
.then(verifyUser)
.then(function (user, verifiedToken) { return verifiedToken; })
.catch(function (err) { log(err.stack); });
}

[译] 事件循环,Node.js 背后的核心概念

前言

如果你了解过Node.js,那么你一定听说过事件循环。你一定想知道它为什么那么特殊,并且为什么你需要关注它?此时此刻的你,可能已经写过许多基于Express.js的后端代码,但没有接触到任何的循环。

在下文中,我们会先在一个更高的,无关操作系统的层面上了解事件循环,然后再去深入到Node.js中观察它。

事件和事件处理器

在事件循环里,有两个主要角色:

  • 事件
  • 事件处理器,即这些事件的订阅者

事件,可以是十分底层的操作系统事件,如“文件已经准备好被写入”或“收到了一个新的HTTP请求”。
事件处理器,则是当指定事件触发时,执行的一段代码。

[译] JavaScript ES6 class 指南

前言

EcmaScript 2015 (又称ES6)通过一些新的关键字,使类成为了JS中一个新的一等公民。但是目前为止,这些关于类的新关键字仅仅是建立在旧的原型系统上的
语法糖,所以它们并没有带来任何的新特性。不过,它使代码的可读性变得更高,并且为今后版本里更多面向对象的新特性打下了基础。

这样做的原因是为了保证向后兼容性。也就是,旧代码可以在不做任何hack的情况下,与新代码同时运行。

[译] JavaScript ES6 迭代器指南

前言

EcmaScript 2015 (又称ES6)提供一个全新的迭代器的概念,它允许我们在语言层面上定义一个(有限或无限的)序列。

暂时先抛开它。我们对于for循环以及它的兄弟for-in循环,都已经十分的熟悉。后者可以被用来帮助我们理解迭代器。

1
2
3
for (var key in table) {
console.log(key + ' = ' + table[key]);
}

对于for-in循环,它有许多的问题。但是最大的问题,便是它不保证迭代的顺序。但是当我们使用ES6迭代器时,这个问题就迎刃而解了。

[译] JavaScript ES6 解构赋值指南

前言

让我们来仔细地看看ES6所带来的更清晰的变量声明与赋值语法。现今的变量声明语法十分的直接:左边是一个变量名,右边可以是一个数组:[]的表达式或一个对象:{}的表达式,等等。解构赋值允许我们将右边的表达式看起来也像变量声明一般,然后在左边将值一一提取。听起来有点迷糊?让我们一起看看下面的例子就好。

数组的解构赋值

现在假设我们有一个value变量,其值为[1, 2, 3, 4, 5]。然后我们想给数组的前三个元素分别声明一个变量。传统的做法是单独声明和赋值每一个变量:

1
2
3
4
var value = [1, 2, 3, 4, 5];
var el1 = value[0];
var el2 = value[1];
var el3 = value[0];

Node.js 中 spawn 与 exec 的异同比较

前言

众所周知,Node.js在child_process模块中提供了spawnexec这两个方法,用来开启子进程执行指定程序。这两个方法虽然目的一样,但是既然Node.js为我们提供了两个方法,那它们之间必然还是会有一些不同之处,下面让我们来分析一下他们的异同。

首先我们来看看官方API文档中对它们的说明:

child_process.spawn(command[, args][, options])

command String 将要运行的命令。
args Array 字符串参数数组。
options 配置对象:

  • cwd String 子进程的当前工作目录。
  • env Object 环境变量键值对。
  • stdio Array|String 子进程的stdio配置。
  • detached Boolean 这个子进程将会变成进程组的领导。
  • uid Number 设置用户进程的ID。
  • gid Number 设置进程组的ID。

返回值: ChildProcess对象

利用给定的命令以及参数执行一个新的进程,如果没有参数数组,那么args将默认是一个空数组。

一起来实现 co(Promise 化的 4.X 版)

前言

大名鼎鼎的co正是TJ大神基于ES6的一些新特性开发的异步流程控制库,基于它所开发的koa更是被视为未来主流的web框架。之前在论坛也看了不少大神们关于co源码的分析,不过co在升级为4.X版本时,代码进行了一次颇有规模的重构,从先前的基于thunkify函数,改变成了现在的基于Promise,并且可能在未来版本移除对thunkify函数的支持。正好小弟最近也在看TJ大神的源码,也来分享一下co(4.X)的实现思路以及源码注解。

进入正题

以下是两段co(4.X)的经典使用示例:

1
2
3
4
5
6
7
8
co(function* () {
var result = yield Promise.resolve(true);
return result;
}).then(function (value) {
console.log(value);
}, function (err) {
console.error(err.stack);
});

用 ES6 重写 《JavaScript Patterns》中的设计模式

前言

最近在回顾设计模式方式的知识,重新翻阅了《JavaScript模式》(个人感觉也算是一本小有名气的书了哈)一书,读时总有感触:在即将到来的ES6的大潮下,书中的许多模式的代码可用ES6的语法更为优雅简洁的实现,而另一些模式,则已经被ES6原生支持,如模块模式(99页)。所以自己动手用ES6重新实现了一遍里面的设计模式,算是对其的巩固,也算是与大家一起来研究探讨ES6语法的一些最佳实践。

目录

(以下所有例子的原型均为《JavaScript模式》一书里“设计模式”章节中的示例)

代码repo地址,欢迎star,欢迎follow。

[译]从 coffeeScript 迁移到 ES6

从coffeeScript迁移到ES6

我在多年前爱上了coffeScript。对于javaScript,我一直保持着深沉的爱,也十分高兴得看到node.js的快速发展,但是作为一个有python背景的程序员,我更喜欢coffeeScript的简练语法。
在任何一个活跃的社区中,事物的迭代更新都是必然的,现在,我们看见了javaScript向着ES6标准的巨大进步。ES6包含了相比于CoffeeScript更多好的特性,并且通过如Babel这样的工具,我们已经可以开始着手使用他们。以下是从coffeeScript迁移到ES6的一些注意点和我的想法。

符号

放弃空格(whitespace),重新转而使用圆括号,花括号和分号。请接受在使用ES6时,你会敲上更多的符号。不过在规范的代码格式下,它们看上去还是挺整洁的。

语法校验

过去我使用的是CoffeeLint,现在我通过babel-eslint来使用ESLint。遵循Airbnb ES6 style guide这个语法风格指南。最好将你的编辑器设置成在输入或保存时进行语法检查。Atom’s eslint plugin这个语法校验插件非常不错,你可以将上面的Airbnb ES6 style guide链接中的内容,放入你的.eslintrc配置文件中。SublimeText也有类似的插件

分享一个写的 node RSS 爬虫,以及主要实现流程

前言

为了更好分享和发布自己的内容,现在提供RSS服务的网站和社区非常之多,现在基于pythonjava等平台的RSS爬虫非常之多,所以结合node高并发特性,自己用node写了一个RSS爬虫——rss-worker

代码地址:这里 , 欢迎star,欢迎follow。