GMTC TypeScript 多场景设计方案及应用实践

前端狗

2019/07/09 发布于 编程 分类

GMTC2019 

文字内容
1. TypeScript 多场景开发实践 Best practices of TypeScript and Dev in Alibaba
2. 陈仲寅 (花名:张挺) 就职于 阿⾥里里巴巴淘宝技术部 MidwayJS 团队 zhangting@taobao.com @czy88840616 @czy88840616 https://github.com/czy88840616
3. MidwayJS
4. MidwayJS
5. MidwayJS Midway Pandora.js Sandbox
6. MidwayJS Midway
7. MidwayJS ⾯面向未来的全栈开发框架
8. TS Review ⾯面向过去,接受历史
9. TS Solve ⾯面向现在,解决问题
10. TS Explore ⾯面向未来,探索未知
11. Node.js Ready ?
12. TS 来看看数据
13. Node.js 2300+ 如今集团总约 1600 个应⽤用 1600+ 700+ 2014 2015 2016 2017 2018 2019.1 2019.5
14. TS ~70% 72.9% 91% 5% BFF 使⽤用框架 接⼊入治理理 使⽤用 TS
15. TS 来看看问题
16. TS 复杂度逐步增加 - 全栈应⽤用 ⾯面向外部⽤用户 - ⼤大流量量 成为中流砥柱 - 核⼼心应⽤用
17. 调⽤用 http 服务,没有调⽤用定义 提供 RPC 接⼝口时,需要写 JSDoc TS
18. TS Node.js 测试靠⼈人⾁肉
19. Node.js Import TypeScript
20. TS 我们都知道 TypeScript 的优势 1 2 3 类型描述 更更多的 Feature ⽀支持 ⾯面向接⼝口编程
21. TS 个⼈人开发⾯面向类型编码, 协作时⾯面向接⼝口编程
22. TS 开发时增加更更多接⼝口定义, 数据定义,参数定义
23. TS 跨协议转换
24. TS 进⼊入正题 进⼊入正题 我们是来解决问题的
25. TS Why is Midway Egg 是个好框架 Egg 有⾃自⼰己解决的东⻄西 Midway 解决的痛点不不同,不不是⾮非常适合我们的情况 by TypeScript
26. TS 定位不不同 在内部体系中,Egg作为底层框架,不不直接使⽤用
27. TS 场景不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景
28. TS 场景不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景 除了了明确意义的 controller service 承载了了太多的职能。
29. TS 场景不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景 ⼦子⽬目录缺乏⽀支持
30. TS 体验不不同 我们希望引⼊入 TypeScript 原⽣生的体验
31. TS 体验不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景 ├── src │ ├── │ ├── │ ├── │ └── app.ts app.js app.d.ts app.js.map js/ts ⽬目录混合
32. TS 体验不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景 class ⽤用法,⽆无法多继承
33. TS 体验不不同 Egg 解决的是 BFF 场景,⽽而淘宝有不不少全栈场景 杂糅的 app/ctx 合并机制
34. TS 第⼀一代设计 第⼀一代设计
35. TS 解决复杂度问题 尝试引⼊入 IoC 解决复杂业务的问题
36. 配置 TS 使⽤用描述⽂文件创建实例例(xml) 很早就开始使⽤用 ioc 注⼊入的⽅方式,苦于 js ⼀一 直没有很好的实践产品。
37. TS 配置 使⽤用描述⽂文件创建实例例(xml)
38. 升级 ⾃自动化装配 TS 使⽤用 inversify 的⾃自动化 优势:简单,功能精简 劣势:满⾜足不不了了⾃自定义的需求(xml)
39. TS
40. TS
41. TS
42. ⾃自研 TS ⾃自研 injection 100%满⾜足⾃自⼰己的需求,整体代码⾃自⼰己能掌握,同时更更简单
43. @provide() export class UserService { 关键字 @inject() userManager: UserManager = new UserManager(); async getUser(id: number) { return this.userManager.get(id); } } TS ⾃自研 ⾃自研 injection
44. @provide() export class UserService { 关键字 @inject() userManager: UserManager; async getUser(id: number) { return this.userManager.get(id); } } TS ⾃自研 ⾃自研 injection
45. 请求 A类 α对象 B类 β对象 C类 TS Ω对象
46. 请求 A类 B类 IoC容器器 α对象 β对象 C类 TS Ω对象
47. 请求 IoC容器器 A类 B类 α对象 TS C类 β对象 Ω对象
48. TS 解决体验问题 尝试让⽤用户体感⼀一致,不不再考虑写法 服务层写法⼀一致,体验⼀一致
49. 体验上的问题 1、写法上的不不⼀一致 - Class / Function 2、多实现上的不不⼀一致 - ⽆无法⽅方便便的继承 3、代码洁癖上的问题 - 编译⽬目录分离 TS
50. 体验 TS 统⼀一使⽤用 class/interface 为了了良好的使⽤用 IoC,我们将整个 Midway 修改为了了 OO 的模型,所有的东⻄西都通过 class 来编码,这样也 可以更更好的借鉴 java 的思想,另⼀一⽅方⾯面可以通过接⼝口 来解决多实现的架构。
51. TS 体验 统⼀一使⽤用 class/interface
52. 体验 TS 增加接⼝口描述 集团中间件缺少描述,补充了了⼤大概 10 ⼏几个类的定义, 这样通过注⼊入就不不需要额外再摸索。
53. TS 体验 增加接⼝口描述
54. TS 第⼆二代设计 第⼆二代设计
55. TS 解决 Egg.js 体验 虽然服务层的使⽤用已经解决了了,但是和 egg 耦合的部分还是沿⽤用了了 egg 的写法,虽然有 变通的办法,但是需要在体验上更更进⼀一步。
56. TS 和 Egg.js 解耦 保留留 Egg.js 的能⼒力力同时做出提升 1、保留留原有能⼒力力,可以快速迭代升级(继 承 egg-loader) 2、实现装饰器器的⽅方式,利利⽤用现有的 API, 附加能⼒力力,⽐比如 loader 的扩展, loadController,load系列列的
57. TS 和 Egg.js 解耦 保留留 Egg.js 的能⼒力力同时做出提升
58. TS 和 Egg.js 解耦 保留留 Egg.js 的能⼒力力同时做出提升
59. TS 和 Egg.js 解耦 保留留 Egg.js 的能⼒力力同时做出提升
60. TS 和⽬目录解耦 弱化⽬目录约定 做完了了之后,我们发现了了,加载模式的⾃自动 化,通过扫描完全不不需要⽬目录约定。
61. Controller A Controller B Controllers Controller C Controller D MyApp Service A Service B Services Service C Service D TS 和⽬目录解耦 弱化⽬目录约定
62. Controller A Service A MApp1 Controller B MApp2 Service B MyApp Controller C MApp3 Service C MApp4 Controller D Service D TS 和⽬目录解耦 弱化⽬目录约定
63. TS 和⾃自⼰己解耦 基于新的装饰器器开发模型 实现和定义分离
64. @controller @get/post @priority @plugin @config @logger @hsf @schedule @func Import { controller } from ‘@midwayjs/decorator’ TS 和⾃自⼰己解耦 基于新的装饰器器开发模型
65. 休息⼀一下 休息⼀一下
66. TS ⾯面向未来的设计 ⾯面向未来的设计
67. TS 跨场景的设想 定义与实现分离 Web场景/⾃自启动场景/更更多⾃自定义场景。 正好碰上了了 Serverless 的浪潮,作为集团唯 ⼀一的 Node.js 架构团队,集团的领航者当仁 不不让的投奔进去。
68. TS 代码重构实践 分离通⽤用层 分离 midway-core,将通⽤用的能⼒力力都放在这层
69. TS 代码重构实践 egg 耦合 Web 装饰器器实现 分离通⽤用层 1、⾃自扫描注⼊入 ioc 的能⼒力力 2、适配 midway 的请求作⽤用域能⼒力力 ⾃自动绑定 装饰器器定义 IoC 请求作⽤用域 3、兼容原有装饰器器的能⼒力力
70. TS 代码重构实践 egg 耦合 Web 装饰器器实现 分离通⽤用层 1、⾃自扫描注⼊入 ioc 的能⼒力力 Midway-Core 2、适配 midway 的请求作⽤用域能⼒力力 3、兼容原有装饰器器的能⼒力力 Decorator Manager IoC
71. Controller A Claas Meta ControllerKey 代码重构实践 Controller C Class Meta 分离通⽤用层 @controller Schedule A Claas Meta ScheduleKey @schedule Schedule B Class Meta Autoload A Claas Meta AutoloadKey Autoload B Class Meta @autoload TS Controller B Class Meta Decorator Manager 承载着⾃自定义装饰器器的核⼼心
72. First: saveModule function autoload() { return function (target, propertyKey, descriptor) { saveModule(‘autoload’); } } Second: listModule const modules = listModule(‘autoload’); // TODO something TS 代码重构实践 分离通⽤用层 Decorator Manager 承载着⾃自定义装饰器器的核⼼心
73. TS Express/Koa 传统 Web 场景初试 我们花了了⼤大概 200 ⾏行行代码,简单实现了了在 express ,相同的代码,但是不不同的场景。 同样的,我们尝试在 typeorm 领域,扩充我 们的装饰器器。
74. TS Express/Koa 传统 Web 场景初试
75. TS Express/Koa 传统 Web 场景初试
76. TS 跨场景 不不同场景公⽤用⼤大部分装饰器器
77. TS 同场景跨类型 类似场景复⽤用装饰器器
78. Midway-egg Midwayexpress Midway-koa Midway-rpc Midway-core Injection Midway-faas TS Midway-orm Midwayschedule
79. Midway-bin midway-Jar2pxoy Midway-faas-mock Midway-egg Midwayexpress midway-faas-fun midway-rpc-generator Midway-koa Midway-rpc Midway-core Injection TS Midway-mock Midway-rpc-mock Midway-faas Midway-Definition Midway-orm-tools Midway-orm Midwayschedule
80. TS Serverless 场景 前端绝佳的机会
81. TS FaaS 初探 ⼀一些概念 平台 ⽹网关 函数 触发器器(事件) 运⾏行行时
82. ⼀一些概念 API Gateway Fn Fn Node.js Runtime K8S TS FaaS 初探 User Fn
83. User API Gateway Fn Node.js Runtime K8S TS FaaS 初探 ⼀一些概念
84. API Gateway Fn Server Router Node.js Runtime TS FaaS 初探 ⼀一些概念 Middleware
85. API Gateway TS FaaS 初探 Router ⼀一些概念 Fn Business Code Node.js Runtime Server Middleware
86. TS FaaS 框架 为什什么需要框架 我们调研了了业界的⼤大部分 Serverless 的开发平台和开发的私 ⽤用习惯,虽然业务不不同,但是业务的代码量量依旧可观。
87. TS Midway-FaaS 实现⼩小⽽而美 ⽬目标: 1、体验⼀一致,⽅方便便代码模块迁移 2、跨平台发布
88. TS Midway For Egg 600 line Midway-FaaS 实现⼩小⽽而美 Midway For Koa 220 line Midway For Express 240 line Midway For FaaS 120 line 符合全栈场景的框架, ⽀支持 koa 作为基础框架, ⽀支持 express 作为基础框 极简的 for FaaS 场景 ⽀支持 egg 插件体系的完 包含最简单单进程场景的 架,包含最简单单进程场 的⽀支持 IoC 的最⼩小框架 整版本。 midway 适配版本。 景的 midway 适配版本。 版本。 Selected
89. TS 从 Web 到 FaaS 场景切换,代码⼀一致 ⾸首先是⼊入⼝口的变化,装饰器器的不不同 @func,⽤用⽼老老办法处理理。
90. 从 Web 到 FaaS TS 场景切换,代码⼀一致
91. TS 跨平台的考虑 多个平台的⼀一致性考虑 1、调⽤用⽅方式的不不同 2、数据参数的不不同 3、描述⽂文件的不不同 不不同的平台需要有不不同的的调⽤用⽅方式,由于 typescript 的编 译⽬目录不不同,可以通过构建的阶段将⼊入⼝口⽂文件动态创建进去。
92. TS 跨平台的考虑 FaaS Dir src 多个平台的⼀一致性考虑 index.ts dist index.js package.json
93. TS 跨平台的考虑 FaaS Dir src 多个平台的⼀一致性考虑 index.ts dist index.js package.json index.js
94. TS 总结⼀一下 总结⼀一下 我们通过 IoC,解决了了困扰我们多年年的全栈开发问题。 我们通过装饰器器,解决了了和某个框架依赖过深的问题 我们通过多场景,拓拓宽了了 Node.js 的开发职能,也创造了了前端的新场景
95. THANKS! THANKS THANKS!