最近接手了 DEF 的维护开发,一直在读代码、读代码、读代码,是时候整体对 DEF 做个总结回顾,同时畅想下未来了。这里面很多都是我自己的理解,如果有不对的地方,欢迎大家指出,一起讨论。
DEF 的全称是 Development Environment for FED(不过,据小道消息已经改名为:Development Ecosystem for FED,更能体现 DEF 的平台性)。DEF 的定位是在硝烟四起(开发工具重复建设)、荆棘密布(规范参差不齐)中建立一个整合前端开发中各种工具、环境的平台。
在 2013 年底 DEF 小组横空出世,于 2014 年 2 月,发布了第一个内测版本。经过 “冷启动” 中 “种子” 用户的试用反馈,DEF 不断优化,在 2014 年 4 月发布了第一个正式版本,开始了漫漫征途。
我们知道,随着应用复杂性的增加,前端项目早已不是简单的几个 JS 文件和 CSS 文件了,而是越发的复杂和精细化。我们会建立标准,统一目录结构,将功能分解为各个小模块(require、exports)。然后,在发布前对代码进行构建(build),执行合并、打包、压缩。
可以看出,这其实就是一种抽象的工作流程。落实到实现上,我们需要解决几个问题:
DEF 给出了自己的答案:
DEF 解决了前端工程中非常重要的问题:目录结构规范,代码构建。同时通过插件机制,诞生了各种各样的工程规范(标准)。
我们先来看看近 1 个月来 DEF 收集到的 2 组数据。
DEF 插件调用量:
DEF 命令使用量:
从上面的图表里面我们可以分析出下面几个结论:
如果我们仔细分析会发现,上面这样的使用数据其实反映出前端开发正在形成标准的开发流程。
def init
形成目录规范def kimi dev
、def tms dev
进行本地调试def build
或者云构建进行代码构建def ff
、def kimi awp
进行代码部署和发布def ci
进行持续集成及单元测试def lint
进行代码规范检查标准的开发流程,这不正是工程化吗!有了标准的开发流程,一群搬砖的就可以造出宏伟的高楼大厦,想想都有些小激动呢。
但是 DEF 目前提供的工程化功能不是很规范,还有点点“混乱”的感觉。但是其实这是非常合理的情况,因为必然要经过工具的百花齐放,才能博采众长,通往规范统一的工程之路。
这里试举几个例子。
比如,我在某个目录下进行本地调试应该执行 def dev
就好了,配置里面指定了套件类型,没必要再加上额外参数,因为我不可能去一个 KIMI 的项目里面执行 def tms dev
。
再比如,代码的部署、发布,我希望执行 def deploy
就部署,至于部署到哪(是存放无线 HTML 页面的 AWP,是存放 JS、CSS 的 CDN、还是 Node.js 应用的服务器),我们通过配置约定好,你照着发就行,我没必要重新用另外的命令操作。
再再比如:执行代码规范检查、单元测试、持续集成,我希望我部署代码到远程以后就给我把该跑的全跑了,有问题再告诉我。当然,也会给对自己严格要求的开发者提供本地运行的命令。
最后,为了减少用户切换 context 的消耗,所有这些信息应该在一个平台展示,就算背后系统是多个,也应该“伪装”成一个展示给用户。
有了对“现状”的分析,我觉得 DEF 对工程的支持应该是这个样子:
最左侧是相关的工程套件,上面是工程生命周期相关的命令(目前暂时统一为 5 个)。命令会根据不同的工程套件,使用底部的一系列服务、系统(对使用者其实是透明的)来提供不同功能。
由于复杂性都隐藏在内部,暴露的命令是统一、标准的,这对使用者来说就变得非常简单。
比如我要开始一个 web 项目,执行 def init
后选择相关的套件类型(kit-web),此时套件类型已经确定,后面执行的命令都将依据套件来做出不同的表现。
本地调试执行 def serve
开启服务器(可能会加参数来开启远程调试 sync 服务)。
构建一般来说直接走云构建,如果你非要本地构建,执行 def build
后会从云端下载套件对应的构建器 builder 在本地执行构建过程。
检测会是一个包含很多东西的操作,理论上是执行部署时会在云端去运行配置好的检测任务(比如:安全检查),也会暴露本地检测的命令供开发者使用(比如:单元测试、规范检查),有些检测过程可能还需要用户参与(比如:代码 Review)。
最后部署发布,直接执行 def deploy
就可以将各种资源(比如:JS、CSS、HTML、甚至是 Node.js 应用等等)进行发布(通过参数区分发布到日常还是线上)。
于是,DEF 2.0 可以这样来描述:整合插件及各种系统,将流程标准化,为开发者提供统一的、工程化的服务——工程套件。
DEF 平台由 3 大部分组成:
整体的架构图如下所示:
DEF 客户端是离用户最近的部分。包括:
命令行工具 DEF CLI 类似操作系统里面的 shell,接受用户输入,处理参数,调用内核来完成具体功能。
可编程的 DEF Core 类似于操作系统的内核,是真正做事情的,能够基于内核进行二次开发(比如,我们完全可以调用内核来打造一个拥有图形化界面的 DEF GUI)。
DEF Home 类似于操作系统里面的用户目录,用来存放用户安装的插件(套件),用户的配置信息。DEF Core 会加载此目录下的插件(套件)来提供功能。
DEF 服务端是给客户端提供各种丰富接口(API)的后台服务。包括:
DEF Store(在线商店)想要解决的问题是:
整个 DEF Store 的结构图如下:
可以看到有 4 部分流程走向:
想要对产品做好优化迭代,收集用户的使用数据是十分必要的。DEF Analytics 就是一个用户行为日志的打点及可视化服务。整体的结构图如下:
在客户端:命令行 CLI 通过 commands 来分发命令的同时会将命令传递给 analytics 模块,此模块会先将使用数据暂时写入配置(不做实时发送,降低服务器的压力),待收集一定数据后(比如:50 条),请求服务端提供的 API 一次性将数据进行发送。
在服务端:会将使用数据进行存储,然后会提供可视化的数据展示界面。DEF Store 也会获取 Analytics 服务的数据(插件的使用量、套件的使用量等)进行展示、做浮现等。
DEF 客户端里经常需要知道当前使用的用户是谁,该如何安全优雅的进行登录验证是一个问题。同时,DEF 作为一个平台,接入的插件(套件)背后可能还有自己的一套系统,如何方便、安全的告诉这些系统当前用户是谁同样是一个需要解决的问题。这就是 DEF UserAuth 服务。
DEF 的做法是,用户登录后为每个用户生成一个随机的私人 token(private token),并在本地记录这个私人 token,后面使用私人 token 请求远程服务时,服务根据私人 token 来获取用户信息。这个 token 每个人都不一样,而且具有随机,不容易“猜到”。而且可以为 token 设置一个过期时间,防止 token 泄露造成的风险。
DEF 登陆验证流程图如下:
这其实就是一种 session 机制,就像我们在浏览器端使用 cookie 记录下 session id,每次请求服务都会再传递 session id,直到 session 过期了就要求用户重新登录。
现在假设用户在 DEF 成功进行了登录,某个插件 X 获取了用户信息后需要请求插件背后提供服务的应用 X 的 API 来操作用户的记录。应该怎样安全、方便的告诉应用 X 当前用户是谁呢?
DEF 实现的验证流程如下:
这种方法的关键点包括:
这样各个应用只需要申请 secret,使用 DEF 提供的 jwt sdk,即可直接解析出用户信息,不再需要各自实现 token 验证。
DEF Notify 其实是一个 YY 中的概念。
我们平常发现,一些比较重要的旺旺消息提醒、邮件提醒等真正被用户注意到的还是比较少的。而 DEF 命令行作为一个极“大”的入口,大家其实是需要频繁“关注”的。我们希望实现一种从服务器实时的向命令行推送消息的服务,这样可以保证一些重要的通知(比如:构建出错、代码检查出错等)可以很快被用户注意到。
整体的交互图如下:
这里实现了一个“抽象”的消息服务,“消息”可以是各种各样的内容,拥有很多想象空间。
比如说:
def robot
,然后向他提各种开发、文档、行政、生活的问题,都会得到解答)DEF Ecology 里面的内容其实很多,包括:偏功能性的各种插件、拥有标准流程的工程套件、贡献插件(套件)的开发者、DEF 插件(套件)的开发规范、支撑插件(套件)的各种系统。
这是一个充满自由又满是约束的世界。自由在通过插件贡献各种各样的工具。约束在通过套件封装标准统一的工作流程。
这一部分的美丽图片应该是每位开发者一起携手来画出的!
这篇文章把 DEF 梳理了一遍,并提出了我们未来努力的目标,说的比较多,可能干货比较少。等真正开始实现时,会对里面的一些实现、技术细节进行更加详细的解说。
关于题图:在大海航行的船,https://pixabay.com/zh/日落-船海-船舶-675847/,DEF 2.0 也正杨帆起航。
← WebGL 技术储备指南 新版卖家中心 Bigpipe 实践(一) →