浅谈前端并行开发痛点
首先,我们先来看下 url 获取资源的本质,一般情况下一条 url 会请求到代理服务器(nginx)。
代理服务器会帮助我们选择目标资源,我将目标资源分为两类。
一类是静态的(变更频率低),静态的主要包括 html、js、css、图片、视频
一类是动态的(变更频率高),动态是可变的,最主要特点是两次请求返回结果可能不同,json、jsp、ssr、文件导出
当我们通过浏览器发出一个请求时候,一定是这两类中的一类,和前端相关的 80%以上都是在请求静态资源。
如下图
这是我们线上业务的一般态,在测试环境下我们面临的挑战比这个要多一些。
测试环节静态资源与动态资源的关系
n - 0 关系
纯静态类资源的前端场景
这类指的是无需请求动态数据的,这类站点通常是文档站,但是也有特殊的比如一些 playground 、正则校验等。
我们会根据需求切换不同分支,进行开发,这时候的版本是 功能预览版 ,在某种场景下 功能预览版 需要自己的站点。
面临的问题是,如果快速高效的部署自己的功能预览站点?
1 - n 关系
这类指的是前端不变后端变化,后端需要一个和线上一致的测试环境去验证自己的修改是否正确。
面临的问题是,需要保证测试环境一直有一个稳定的线上前端环节。
n - 1 关系
只是前端变动,后端无需变动,这个和 n - 0 关系面临的问题是一样的。
n - m 关系
这是测试环境下最常见的,当一个需求开发时候,我们需要部署一份前端和一份后端,提供给测试同学检验。
这里面临的问题既包括 n - 0 的问题,还存在如何对应把前端与后端关联起来。
针对上面的关系我们总结出需要解决的两个问题点:
- 如何快速部署新功能前端站点
- 如何绑定前端与后端
快熟部署新功能的前端站站点
正常情况下,我们部署前端站点,需要申请一台机器(容器节点),然后配置 ng,将请求指向对应静态资源目录。
这些动作是重复的,所以我们可以引入一个平台去帮我们做这些事情。
假设当前有一个项目 A,正在并行开发功能 A。
平台功能主要包括:
- 资源隔离
对于项目 A 的功能 A,需要存放到资源目录 /项目_A/功能_A,这样只需要根据某些特征值发送这些文件就可以啦。 - 资源映射
两种资源映射操作,动态域名,特征路由
动态域名是指通过子域名进行区分,比如 项目-A--功能-A.ci.com
通过特种路由的方式,通过 header 进行标识要请求那个功能,比如在 header 添加 special-header:项目_A-功能_A
动态域名 | 特征路由 | |
---|---|---|
优点 | 相比于 header 方式用户更方便使用 | 全部场景覆盖 |
缺点 | 对于某些特定场景动态域名无法支持,比如只针对白名单域名进行权限校验等 需要配置接口代理,转发到指定后端 |
需要使用浏览器插件的方式手动注入 header |
-
接口代理绑定前后端
如果使用动态域名的方式我们需要手动指定接口代理,如何搭建一个自己的代理服务?
目前可以有三种方案,nginx 拓展、http-proxy-middleware、whistle
对于前端最好上手的是 http-proxy-middleware 另外两个也可以实现但是相对成本高些。
通过平台提供这些常用的能力就可以满足上面所有场景啦。
好了上面就是如何针对前端并行开发的场景,需要做的一切了,下面是一些个人思考。
一些思考
- 容器化前端场景测试环境是否适用?
不可否认容器技术带来的便利,动态扩容,环境隔离等优势,但是针对测试环境的前端这些优势显然无用武之地。
测试环境的前端没那么大的压力,基本上无需扩容,需要资源极低,更需要的是快速交付给测试同学校验。
然后使用容器,需要启停,打包镜像,显然拉长了这一过程。 - 一个产品能否打到100%完美?
不可能,没有一个产品能达到100%的完美,无论这个产品用户量多大,都是不可能的,原因在于屁股决定脑袋,每个人的屁股是不一样的。