致想用 Node.js 的你
Node.js,09 年这个集成了 Google V8 JavaScript 引擎和一个底层 I/O API 的项目,如今项目无数,大企业也纷纷尝试。
Node.js,09 年这个集成了 Google V8 JavaScript 引擎和一个底层 I/O API 的项目,如今项目无数,大企业也纷纷尝试。
从Node.js进入人们的视野时,我们所知道的它就由这些关键字组成 事件驱动、非阻塞I/O、高效、轻量,它在官网中也是这么描述自己的。
前段时间 Node.js 发布了新版本 4.0,其中涉及到一个更新比较多的模块,那就是下面要介绍的 timer 模块。
Node.js 诞生之初就遭到不少这样的吐槽,当然这些都早已不是问题了。1、可靠性低。 2、单进程,单线程,只支持单核 CPU,不能充分的利用多核 CPU 服务器。一旦这个进程崩掉,那么整个 web 服务就崩掉了。
熟悉 Node.js 的同学一定见过 ETIMEDOUT、EADDRINUSE 等错误提示,那么这些错误信息到底是什么呢?答案其实很简单,因为 Node.js 底层使用的是 glibc 库,这些错误信息都是 glibc 库在 socket 连接时使用的 connect 函数中定义的错误类型,当然,v8在使用glibc库时也会加入一些自定义的错误类型,但许多错误情况还是和glibc中的定义一致的。
上篇文章讲解了 Node.js 中多进程部署时遇到的各种问题,那么实际的线上项目中到底是如何利用多进程,如何保障各个 worker 进程稳定性的呢,又是如何利用 cluster 模块 fork 子进程,父子进程间又是如何实现通信的呢?本篇就来一一揭晓。
笔者最近在研究如何实现页面 HTML 及内联 JS/CSS 的实时压缩功能。首先笔者尝试了在前端模块中扫描内联的 JS/CSS 并压缩,这样还可以集成至前端模块的上传工具中。观察了一段时间发现这样无法处理模板中的 JS/CSS,造成很多遗漏的 JS/CSS 不能压缩。
很多同学在选择 node 的版本管理工具时,可能第一时间就直接使用了 nvm,一般不会再去调研另一个工具 n,更没有闲情去了解这两者的特性和差异。毕竟工具能用就行,没必要搞清其运作机制。
最近在看 koa 的中间件实现时,总是看到 yield* next 这种用法,觉得很困惑。下面是学习成果。
众所周知,PHP 占据了服务端编程语言的半壁江山,正如汪峰在音乐圈的地位一般。随着 Node.js 逐渐走上服务端编程的舞台,关于 PHP 和 Node.js 孰优孰劣的争论也不曾间断。
为了解决传统 Web 开发模式带来的各种问题,我们进行了许多尝试,但由于前/后端的物理鸿沟,尝试的方案都大同小异。痛定思痛,今天我们重新思考了“前后端”的定义,引入前端同学都熟悉的 Node.js,试图探索一条全新的前后端分离模式。
在做前后端分离时,第一个关注到的问题就是渲染,也就是 View 这个层面的工作。
使用 Node.js 做前后端分离的开发模式带来了一些性能及开发流程上的优势(见《前后端分离的思考与实践 一》), 但同时也面临不少挑战。在淘宝复杂的业务及技术架构下,后端必须依赖Java搭建基础架构,同时提供相关业务接口供前端使用。Node.js 在整个环境中最重要的工作之一就是代理这些业务接口,以方便前端(Node.js 端和浏览器端)整合数据做页面渲染。如何做好代理工作,使得前后端开发分离之后,仍然可以在流程上无缝衔接,是我们需要考虑的问题。本文将就该问题做相关探讨,并提出解决方案。
在前后端分离的开发模式中,从开发的角色和职能上来讲,一个最明显的变化就是:以往传统中,只负责浏览器环境中开发的前端同学,需要涉猎到服务端层面,编写服务端代码。而摆在面前的一个基础性问题就是如何保障 Web 安全?
近年来各站点基于 Web 的多终端适配进行得如火如荼,行业间也发展出依赖各种技术的解决方案。有如基于浏览器原生 CSS3 Media Query 的响应式设计、基于云端智能重排的「云适配」方案等。本文则主要探讨在前后端分离基础下的多终端适配方案。
关于前后端分享的思考,我们已经有五篇文章阐述思路与设计。本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践。