个人信息保护法,核心细节有哪些?
发布时间:2022-06-27 16:15:27 所属栏目:安全 来源:互联网
导读:随着 TypeScript 的流行,类型系统也逐步进入了大家的视野,类型安全相关的问题也受到了更多人的关注,那今天我就以这个角度带大家感受 Farrow 在类型安全方面优秀方案的设计与思考,希望对大家能有所启发。 好,那我们现在开始。 类型安全 关于类型安全,可
随着 TypeScript 的流行,类型系统也逐步进入了大家的视野,类型安全相关的问题也受到了更多人的关注,那今天我就以这个角度带大家感受 Farrow 在类型安全方面优秀方案的设计与思考,希望对大家能有所启发。 好,那我们现在开始。 类型安全 关于类型安全,可能很多同学已经有所了解,也了解过 Soundness [1] 这个词,但也该也有许多同学不甚了解。 不了解的同学,你可以暂且将它简单的理解为: 变量的行为与它的类型相匹配,不存在运行时的类型错误。 在 JavaScript 中进行下面几个操作: 访问 null 的属性 将 string 类型当作 number 类型做运算 调用对象不存在的方法 都会在运行时抛出类型错误。 那我们为什么要追求类型安全? Well typed programs cannot go wrong.—— By Robin Milner 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 为例来看一下。 请求意外挂起(Hanging Request) 我们发现以 Express 这样的中间件设计,它允许请求可以不被响应,也无法通过 TypeScript 的类型检查得到约束和提示。 6. 也无法在编译期约束只发送一次 body 复制 篡改对象属性(Monkey Patching) 在 JavaScript 中,我们可以任意的修改对象的属性,但修改 req/res 或 ctx 污染全链路中间件的类型。这会导致,在任意一个中间件中,你都无法知道传到当前中间件的对象中到底有哪些属性和方法。 复制 app.use((req, res, next) => { // what type of res.locals res.locals.a = 1; next(); }); app.use((req, res, next) => { // what type of res.locals console.log(res.locals.a); }); 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 当然有些框架支持一些类型标注的方案,来解决类型提示上的问题,但这并没有从根本上解决问题,从类型系统的角度来看,动态追加的属性或方法,与静态标注的类型有本质矛盾,正确的方式是 让静态类型决定能否赋值属性,而非属性赋值决定是否包含特定类型。 如果请求参数比较复杂,通常需要编写很复杂的校验逻辑。 不友好的类型推导(Poor Type Inference) 现有框架在请求内容和响应内容的类型方面基本没有提供比较好的类型推导方案,很多时候我们需要手动的类型校验 + 类型转换。 复制 app.get('/user/:userId', (req, res, next) => { req.params.userId; // no type infer const params = req.params as { userId: string }; const userId = Number(params.userId); // 必须每次手动 transform }); 1. 2. 3. 4. 5. 问题 到现在,我们已经提到了 5 条现有 API 设计中的类型问题: Hanging Request(请求意外挂起) Wrong Response(错误响应内容) Monkey Patching(篡改对象属性) No Runtime Validation(无运行时验证) Poor Type Inference(不友好的类型推导) 虽然这些框架不是使用 TypeScript 实现,但它们都提供了 @types/* 的类型包,但依旧存在诸多类型上的问题,可见只靠 *.d.ts,并不能获得充分的类型友好和类型安全特性。 我们对这些问题和现有的 Node.js 框架进行了系统性的调研和考量,发现: 基于 Express/Koa 可以用打补丁的方式解决一两种类型问题,但不能从根本上解决问题 Fastify 提供了基于 JSON Schema 的运行时校验请求内容的方案,但方案与类型系统不贴合 要充分解决系统性问题,则需要基于 TypeScript 做全盘的思考 Type-First Development 类型优先开发 Embedded Runtime-Validation(内置运行时验证) Excellent Type Inference(出色的类型推导) Farrow 作者:做到之前做不到,做好之前能做到。 从而就有了 Farrow 这样一个框架,接下来我就向大家介绍一下,Farrow 的一些设计和它是如何做到上面所说的事情。 (编辑:应用网_丽江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |