这是我参与「第五届青训营」笔记创作活动的第十六天
编写Http Server
- 使用框架的好处：上手快，可以直接使用框架提供模式，也可以很方便的使用基于框架封装的插件
- 使用框架的坏处：如果有定制化的需求，如果对原生的模块没有了解的话，可能就没办法满足这些需求，可能只能向社区提个需求|issue，说能不能帮我解决这个问题，但在时间上和会不会解决，这里就要打个问号了 (了解底层，对问题的排查也会有帮助)
例一 HTTP Server
例二 HTTP Client
当代码变得复杂，callback会给管理和维护带来较大的负担 (比如说嵌套Callback，当Callback非常的深，常常会出现我们找得到代码的位置，但我们很难看懂代码的含义，也很难确定具体功能触发的时间) (具体可以查一下回调地狱相关的资料)，下面会使用Promise + Async + Await进行重写
例三 Promisify
如果我们的代码遵循Node.js的代码约定，那我们就可以通过Node.js util中的promisify函数来帮我们实现把callback改写为Promise的这个过程了
注：不是所有的callback都能改写为Promise的这种形式 (比如需要多次执行的callback，就不适合改成Promise的形式，只需执行一次的更适合改造为promise的形式)
静态文件
前置知识：Stream风格的API有什么好处
内部做了处理，可以帮助你占用尽可能少的内存空间 (比如说使用fs.read我们需要把整个文件都读到内存中，而stream API则没有这个问题，在大文件下，stream API的优势就格外明显了)，能用stream就用stream
React SSR
前置知识补充：
QPS：全名 Queries Per Second，意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
简单的说，QPS = req/sec = 请求数/秒。它代表的是服务器的机器的性能最大吞吐能力。
服务器的 QPS 一般我们可以使用 http_load 来测试，统计处 web 服务器的吞吐量和负载。
SSR难点
- 普通的前端应用可能通过打包工具做了很多事情，比如说通过CommonJS 的 require语句将ss文件，图片等也加载进来，比方说Webpack，会动态地把这些文件加载进来。但这在服务端是没有意义的，我们是想去避免它的，为此，我们可能需要改一下打包工具的配置，或者改一下打包工具，甚至要改造下自己的代码
- 比如说我们需要拉数据，那么在服务端渲染时，我们需要把这个函数放在较后的生命周期里，这样才能避免在服务端被执行
部署
当我们要把代码部署到生产环境上时，我们需要一些工具来保证这些进程的稳定运行
- 最常见的就是
pm2这些守护进程的工具 (记录进程的状态，帮你启动进程，如果这些进程退出了的话，它会直接把这些进程拉起来) - cluster充分利用cpu
- 现在用的较多的是容器环境
衍生话题
Node.js贡献代码
Node.js Core贡献入门talks/contributing-to-node-core.pdf at master · joyeecheung/talks (github.com)
