浅谈前端并行开发痛点

语言: CN / TW / HK

首先,我们先来看下 url 获取资源的本质,一般情况下一条 url 会请求到代理服务器(nginx)。

代理服务器会帮助我们选择目标资源,我将目标资源分为两类。

一类是静态的(变更频率低),静态的主要包括 html、js、css、图片、视频

一类是动态的(变更频率高),动态是可变的,最主要特点是两次请求返回结果可能不同,json、jsp、ssr、文件导出

当我们通过浏览器发出一个请求时候,一定是这两类中的一类,和前端相关的 80%以上都是在请求静态资源。

如下图

这是我们线上业务的一般态,在测试环境下我们面临的挑战比这个要多一些。

测试环节静态资源与动态资源的关系

n - 0 关系

纯静态类资源的前端场景

这类指的是无需请求动态数据的,这类站点通常是文档站,但是也有特殊的比如一些 playground 、正则校验等。

我们会根据需求切换不同分支,进行开发,这时候的版本是 功能预览版 ,在某种场景下 功能预览版 需要自己的站点。

面临的问题是,如果快速高效的部署自己的功能预览站点?

1 - n 关系

这类指的是前端不变后端变化,后端需要一个和线上一致的测试环境去验证自己的修改是否正确。

面临的问题是,需要保证测试环境一直有一个稳定的线上前端环节。

n - 1 关系

只是前端变动,后端无需变动,这个和 n - 0 关系面临的问题是一样的。

n - m 关系

这是测试环境下最常见的,当一个需求开发时候,我们需要部署一份前端和一份后端,提供给测试同学检验。

这里面临的问题既包括 n - 0 的问题,还存在如何对应把前端与后端关联起来。

针对上面的关系我们总结出需要解决的两个问题点:

  1. 如何快速部署新功能前端站点
  2. 如何绑定前端与后端

快熟部署新功能的前端站站点

正常情况下,我们部署前端站点,需要申请一台机器(容器节点),然后配置 ng,将请求指向对应静态资源目录。

这些动作是重复的,所以我们可以引入一个平台去帮我们做这些事情。

假设当前有一个项目 A,正在并行开发功能 A。

平台功能主要包括:

  1. 资源隔离
    对于项目 A 的功能 A,需要存放到资源目录 /项目_A/功能_A,这样只需要根据某些特征值发送这些文件就可以啦。
  2. 资源映射
    两种资源映射操作,动态域名,特征路由
    动态域名是指通过子域名进行区分,比如 项目-A--功能-A.ci.com
    通过特种路由的方式,通过 header 进行标识要请求那个功能,比如在 header 添加 special-header:项目_A-功能_A
动态域名 特征路由
优点 相比于 header 方式用户更方便使用 全部场景覆盖
缺点 对于某些特定场景动态域名无法支持,比如只针对白名单域名进行权限校验等
需要配置接口代理,转发到指定后端
需要使用浏览器插件的方式手动注入 header
  1. 接口代理绑定前后端

    如果使用动态域名的方式我们需要手动指定接口代理,如何搭建一个自己的代理服务?

    目前可以有三种方案,nginx 拓展、http-proxy-middleware、whistle

    对于前端最好上手的是 http-proxy-middleware 另外两个也可以实现但是相对成本高些。

通过平台提供这些常用的能力就可以满足上面所有场景啦。

好了上面就是如何针对前端并行开发的场景,需要做的一切了,下面是一些个人思考。

一些思考

  1. 容器化前端场景测试环境是否适用?
    不可否认容器技术带来的便利,动态扩容,环境隔离等优势,但是针对测试环境的前端这些优势显然无用武之地。
    测试环境的前端没那么大的压力,基本上无需扩容,需要资源极低,更需要的是快速交付给测试同学校验。
    然后使用容器,需要启停,打包镜像,显然拉长了这一过程。
  2. 一个产品能否打到100%完美?
    不可能,没有一个产品能达到100%的完美,无论这个产品用户量多大,都是不可能的,原因在于屁股决定脑袋,每个人的屁股是不一样的。