随着TypeScript的流行，类型系统逐渐进入了大家的视野，与类型安全相关的问题也受到了更多的关注。今天，我将从这个角度向大家展示Farrow在类型安全方面的出色解决方案。希望对大家有所启发。在这篇文章中，我将为您带来以下内容：TypeSafetyWhat&Why？Node.js主流Web框架现状当前API设计中的类型问题Farrow类型安全解决方案Farrow的未来规划好了，现在开始吧。类型安全关于类型安全，很多同学可能已经对它和Soundness[1]这个词有所了解，但应该也有很多同学不太了解。不知道的可以简单理解为：变量的行为与其类型相匹配，运行时不会出现类型错误。在JavaScript中执行以下操作：访问null属性、将字符串类型视为数字类型、调用对象上不存在的方法，所有这些都会在运行时抛出类型错误。那么我们为什么要追求类型安全呢？类型好的程序是不会出错的。——罗宾·米尔纳1978年《A Theory of Type Polymorphism in Programming》[2]正如上面这句话所说，类型系统可以有效提高程序的正确性：通过编译时的类型检查，尝试提前捕获可能的程序错误，提高代码的健壮性有了编辑器类型提示，类型检查比单元测试反馈更快、更早、更全面的实时测试。类型检查更优雅更清晰的优点不用多说，为了让我们的代码达到类型安全的状态，我们往往需要对要解决的问题进行建模，所以从这个角度来说，类型系统也可以帮助我们编写设计更好、质量更高的代码。主流框架现状我们之前在实际项目开发中遇到过Node.js框架选择的问题。经过研究，我们发现主流的Node.js框架：Express.js、Koa、EggJS、Hapi、Restify、Fastify等都是用JavaScript实现的，它们充分发挥了Javascript的能力，但是从类型安全，目前web框架的设计存在很多问题。API设计类型问题接下来我们以Express为例。意外的挂起请求（HangingRequest）我们发现像Express这样的中间件设计，它允许请求不被响应，并且无法通过TypeScript类型检查获得约束和提示。app.use((req,res,next)=>{//donothing});错误的对应内容（WrongResponse）同样，我们也不能保证像header->bodyapp.use((req,res,next)=>{//body是提前发送的responsesequenceres.end('xxx');//header必须在body之前发送，这里是error或者warningres.header('Content-Type','text/html');});也不能约束只发送一次bodyapp.use((req,res,next)=>{//body提前发送res.end('xxx');//body只能发送一次，这里报错或warningres.json({error:true});});而这些都会导致错误的响应内容。篡改对象属性（MonkeyPatching）在JavaScript中，我们可以任意修改对象属性，但是修改req/res或ctx会污染全链接中间件的类型。这将导致，在任何中间件中，你无法知道传递给当前中间件的对象中有哪些属性和方法。app.use((req,res,next)=>{//whattypeofres.localsres.locals.a=1;next();});app.use((req,res,next)=>{//whattypeofres.localsconsole.log(res.locals.a);});当然，有些框架支持一些类型注解的方案来解决类型提示的问题，但这并不能从根本上解决问题，从类型系统的角度来看，动态添加的属性或方法与静态注解的类型有着天生的矛盾。正确的做法是让静态类型决定属性是否可以赋值，而不是让属性赋值决定是否包含特定类型。NoRuntimeValidation（无运行时验证）在当前官方的TypeScript工具链中，TypeScript类型在编译后被擦除。确实，在大多数场景下，类型系统在编译阶段之前就完成了它的任务，但这也导致了一个严重的问题。请求内容未知，通常需要人工验证。app.use((req,res,next)=>{req.body;//bodytypeisany/unknownreq.query;//querytypeisany/unknownconstbody=req.bodyasMyBodyType;//typewllbeeliminated});如果请求参数比较复杂，通常需要编写复杂的验证逻辑。不友好的类型推导（PoorTypeInference）现有的框架在请求内容和响应内容的类型方面基本上没有提供更好的类型推导方案。很多时候，我们需要手动类型验证+类型转换。app.get('/user/:userId',(req,res,next)=>{req.params.userId;//notypeinferconstparams=req.paramsas{userId:string};constuserId=Number(params.userId);//每次都要手动转换});Problem到目前为止，我们在现有的API设计中提到了5类问题：HangingRequest（请求意外挂起）WrongResponse（错误的响应内容）MonkeyPatching（篡改对象属性）NoRuntimeValidation（没有运行时验证）PoorTypeInference（不友好的类型推导）虽然这些框架都没有使用TypeScript实现，但都提供了@types/*类型包，但是仍然存在很多类型问题，可见单靠*.d.ts无法获得足够的类型友好性和类型安全特性。我们对这些问题和现有的Node.js框架进行了系统的调研和思考，发现：基于Express/Koa，可以通过打补丁的方式解决一两类问题，但不能从根本上解决问题。Fastify提供了一种基于JSONSchema的解决方案，用于在运行时验证请求内容，但该方案与类型系统的契合度不高。要全面解决系统性问题，需要基于TypeScript的综合思考Type-FirstDevelopmentType-FirstDevelopmentType-DrivenDevelopment类型驱动开发Type-DrivenDevelopment为了做到这一点并解决上面提到的问题，我们需要一个新的类型安全的服务器端框架。类型安全的服务器端框架设计目标根据前面的问题，我们可以得到类型安全的服务器端框架设计目标：PreventHangingRequest（防止请求意外挂起）RefuseWrongResponse（拒绝错误响应内容）NoneedtoMonkey-Patching（无需篡改对象属性）EmbeddedRuntime-Validation（内置运行时验证）ExcellentTypeInference（优秀的类型推导）Farrow作者：以前做不到，做好之前能做到。于是就有了Farrow这样一个框架，接下来我就给大家介绍一下Farrow的一些设计，它是如何做上面提到的这些事情的。Farrow-HttpDesignPreventHangingRequest&RefuseWrongResponse首先，为了防止意外挂起请求和拒绝错误响应内容，Farrow重新设计了中间件，取消了响应参数，通过返回值来表达响应结果。import{Http,Response}from'farrow-http';consthttp=Http();http.use((request,next)=>{//responseisreturntypereturnResponse.text(request.pathname);});这样TypeScript也可以检查函数的返回值类型是否满足约束条件，如果没有响应或者响应类型不对，就会报错。防止错误响应为了进一步解决错误对应内容的问题，Farrow设计了VirtualResponse虚拟响应对象。Response.text等方法构造简单数据，类似VirtualDOM，不直接产生效果。它在多次使用后合并在一起。在Farrow框架中，header->body的顺序和类型会按照正确的顺序统一处理。import{Http,Response}from'farrow-http';consthttp=Http();http.use((request,next)=>{//responseisreturntypereturnResponse.text(request.pathname).header('abc','efg').text('changedtext');});不需要Monkey-Patching(Request)为了解决Monkey-Patching的问题，即不再推荐和引导开发者修改req请求对象，Farrow设计了VirtualRequest虚拟的request对象，所以传入中间件的request对象不是原来的req对象，而是从中提取出来的plaindata，所以可以通过next(newRequest)向后传递新的request对象，而不用修改原来的目的。import{Http,Response}from'farrow-http';consthttp=Http();http.use((request,next)=>{returnnext({...request,pathname:'/another/pathname',});});http.use((request,next)=>{request.pathname;//isequalto/another/pathname});不需要Monkey-Patching(Response)为了进一步解决Monkey-Patching的问题，Farrow重新设计了中间件管理机制，next会返回下游中间件的response对象，后面可以处理，这样不需要修改res/ctx.body，immutable比mutable更类型友好，preferimmutable。import{Http,Response}from'farrow-http';consthttp=Http();http.use((request,next)=>{letresponse=awaitnext();//合并，组合，过滤，组装一个新的响应returnResponse.header('abc','efg').merge(response);});http.use((request,next)=>{returnResponse.text('helloworld!');});不需要Monkey-Patching(Middleware)虽然前面的方面解决了修改request对象的问题，但是仍然没有解决中间件之间共享变量的问题，所以Farrow提供了Context+Hooks的解决方案，他们的工作机制类似于ReactContext和ReactHooks，类似于跨组件传递数据的方式，跨中间件传递Context数据，这样中间件之间的共享变量就不需要挂载到req对象上了，而且得益于Node.js的新特性Asynchooks，Farrow可以提供按需的、分布式的、细粒度的、关注点分离的、类型安全的ContextPassing机制。import{Http,Response,createContext}from'farrow-http';consthttp=Http();//创建上下文constAuthContext=createContext
