【开源实践🚀】为开源项目写一个闭源产品

1,702 阅读10分钟

【开源实践🚀】为开源项目写一个闭源产品

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第1天,点击查看活动详情

总结和分享我为 Monibuca 流媒体框架开发 Web 管理器 的实践经验。

背景

Monibuca 是什么

Monibuca 是一个开源的 Go 语言开发的流媒体服务器开发框架。具体介绍可点击下方官网链接:

官网地址: m7s.live

作为 Monibuca 团队开发者,需要为 Monibuca 4.0 版本做一个 Web 管理器,用来完成对 Monibuca 实例的细致化管理和控制。

同时,这个 Web 管理器暂时是不开源的。相当于是为一个开源项目做一个闭源的产品。

需求讨论和确定

通过团队讨论,确定开发下图所示功能:

1.png

主要开发者有两人,前端一人,后端一人,我负责前端开发任务,下文主要以前端开发为基调进行阐述。

思考衡量

主要的考量有以下几个方面:

时间成本

时间成本是一个重要因素,团队成员目前都是在业余时间进行开发,如果从 0 开始搞太浪费时间,我们需要借助开源力量。 对于我负责的前端,更是如此,我不可能从 0 开始搞,我也不可能自行设计 UI 和交互,我需要把大量时间放在功能开发上,而不是放在 UI 和交互上。

开发和维护成本

开发和维护成本也是一个重要因素,选择主流实现方式,有助于降低开发和维护成本。 在第一个上线版本前,不要过度设计你的实现,那样会显著增加开发和维护成本。 合理的方式是先以你擅长的主流实现方式,快速完成功能开发,完成之后,再去根据整体情况去调整和优化你的设计。

开发和用户体验

开发体验和用户体验这两者在开源和公司中表现正好相反。开源项目的开发体验大多数情况下是非常好的,因为开发者有足够的决定权去提升开发体验,如选择喜欢的技术栈。而开源项目的用户体验一般是不及公司中用户体验的,因为产品所提供的用户体验对于公司是极其重要的,公司会花费很多成本去提升用户体验。 相比之下,开源项目的用户体验一般弱于公司。

当然这不代表开源项目不注重用户体验, Monibuca Web 管理器在开发和用户体验上都会兼顾。

思考衡量总结

在确定功能,到准备开发的间隔中,建议做一个简单的考量,做到心中有数,运筹帷幄。

开发前

在开发项目前,想清楚一件事情:

那就是要不要在某个开源项目的基础上进行开发,这里我在简单尝试后,选择了在开源项目基础上进行开发。

因为让我去从 0 搭建类似管理后台的 Monibuca Web 管理器,时间和开发成本太大,没必要这样做。

想清楚后,下面我要做的就是找到适合 Monibuca Web 管理器的开源项目模板。 这个开源项目具有以下特征:

  1. 项目 LICENSEMIT 或者 Apache , 避免不必要的纠纷
  2. 项目的 UI 和交互符合 Monibuca Web 管理器,同时简洁美观
  3. 项目采用先进主流技术,如前端采用 tsvitevue3 、 主流组件库 等
  4. 项目架构清晰,功能丰富和完善,文档健全

经过搜索、线上体验、阅读源码等过程,最终确定了以 naive-ui-admin 为开发模板。 如下图所示:

3.png

其官方文档地址: jekip.github.io/docs

选它的理由是因为它具备以上四个特征。还有一个因素,就是我想用用 naive-ui 组件库。

在选择 naive-ui-admin 作为开发模板后,我开始了功能开发。

开发中

联调

整个开发过程,开发和联调是同时存在的,边开发,边联调,有点类似做私活,主要有以下 2 个总结:

  1. 联调时间动态化:因为是业余时间搞,我有空,他不一定有空,所以需要沟通一个都有空的时间点
  2. 联调进度可快可慢:没有截止日期,一个功能,可以很快联调完,也可以联调好几天

边熟悉模板代码,边开发功能

这个主要是参照官方文档,看下核心功能的实现,如路由、权限、布局等。

这个开源模板提供的路由和权限功能非常丰富,功能如下图所示:

5.png

代码实现也比较复杂,后续会对这部分进行优化和简化。不过在开发前期,尽量不要对原有模板代码进行大调整,按照其定下的规则进行开发功能即可。

整理优化点

在开发过程中,对模板代码可以优化的点和如何调整为适合 Monibuca Web 管理器的方案做到心中有数,比如下面几点:

  1. 去掉 mockstylelinthuskyenv
  2. 简化路由、权限
  3. 优化构建、 commitizen 、 代码结构
  4. 删部分减模板项目 UI 和交互

执行优化

在整理优化点后,后面就是执行这些优化,简单的优化在开发前期就解决了,而复杂的优化,需要等熟悉模块代码后,再进行调整。

去掉 mock 、 stylelint 、 husky 、 env

对于人很少的团队来说, mockstylelinthusky 的作用不大,可以删掉。

env 配置,目前也没有用到,以后用到的话,再加上。

简化路由、权限

路由的简化如下图所示:

9.png

图中右侧是 Web 管理器,相较于模板代码,做了以下具体调整和优化

  1. 入口代码精简
  2. 拆分复杂的路由守卫逻辑,拆分逻辑放在 guard 目录下
  3. 根据实际情况,去掉后端生成路由的逻辑

权限的简化: 去掉后台动态路由,只保留前端角色权限。

优化构建、 commitizen 、 代码结构

优化构建:

  1. 去掉了 build 目录,构建逻辑都写在 vite.config.ts
  2. 增加了一些 vite 插件,如 visualizericoninspector ,如下图所示:

11.png

优化 commitizen

主要是将 commitizen 替换成了 czg ,有以下优点:

  1. 轻量级 : 零依赖项
  2. 简单且快速 : 无需前置配置,无需适配器,没有额外的步骤
  3. 可定制化 : 内部包含 cz-git 的核心,继承了 cz-git 的所有特性

操作如下 gif 图所示:

czg 官方文档: cz-git.qbb.sh/zh/guide/

优化代码结构:

优化后的代码结构和模板代码结构对比如下图所示:

12.png

图中右边是优化后的代码结构,从上图可以看到做了以下两点优化:

  1. 增加统一入口
  2. 重新调整目录

提升体验

这里分为开发体验和用户体验。

提升开发体验

主要做了以下措施:

  1. 使用 turbo ,增加多包任务编排能力,如下图所示:

13.png

  1. 使用 pnpm workspace , 增加对第三方 npm 包定制化能力,如下图所示:

14.png

  1. 使用 vite-plugin-vue-inspector , 增加点击 UI 自动定位到代码行能力,如下 gif 图所示:

22.gif

  1. 更新 Vite 版本,配置依赖预构建

提升用户体验

提升用户体验的核心内容,就是要让用户感受到页面很快,交互很友好。

页面很快这个可以通过性能优化来做到,性价比最高的做法如下:

  1. 开启 gzip 压缩、开启 h2
  2. 优化打包体积

在优化打包体积的过程中,使用 rollup-plugin-visualizer 对打包代码进行体积分析,分析结果发现,体积很大, Rendered 体积达到了 4.5M 。 模板代码对这块没有做优化,遂进行优化,优化方式也很模板。就是不构建公共库,使用 cdn 去加载,配置如下:

import externalGlobals from 'rollup-plugin-external-globals'
const globals = externalGlobals({
  vue: 'Vue',
  vueRouter: 'VueRouter',
  'naive-ui': 'naive',
  'vue-demi': 'VueDemi'
})
build: {
  target: 'es2015',
  outDir: 'dist',
  rollupOptions: {
    external: ['vue', 'vue-demi', 'vueRouter'],
    plugins: [globals]
  }
}

然后再把 echart 干掉,不使用 echart 。 这样操作下来,构建分析结果如下图所示:

15.png

Rendered 体积只有 1.1MBgzip 后只有 360KB , 构建体积优化到这里,已经可以了,发布后,页面加载速度提升明显,用户体验也得到不错提升。

上线

开发完功能和自测后,就可以准备上线了,上线过程也非常简单,后端整好后,前端这边写一个构建部署脚本即可。

上线后有一个任务,就是在把线上地址宣传出去之前,团队成员进行提前体验。这个过程点检出了一些问题,如特定操作后,页面空白、代码逻辑问题。

这些都需要在宣传之前解决掉。实际情况中,在宣传之后,依然点检出一些问题,目前的方式就是,发现问题,解决问题,发布上线。

使用教程

现在控制台界面如下图所示:

2.png

有需要的可以用微信扫下面二维码观看视频教程,更加直观。

17.png

未来规划

规划主要有两个,一个是私有化,一个是微模块。

私有化

目前制定了两套方案

第一套方案:

Monibuca Web 管理器私有化,这个需要前端和后端同时做好私有化,这个方案的后端考虑因素比较多,需要做不少调整。

第二套方案:

鉴于 Monibuca 的特殊场景,也就是需要用户在本地启动 Monibuca 实例。我们可以选择桌面端来做私有化,这样就可以不再需要后台服务,只需要写一个桌面端即可。

目前第二套方案的优势更大,不过也要解决一些问题,如桌面端和 WebUI 共用,各操作系统的兼容性等。

微模块

微模块 是跨工程、跨项目共享通用业务代码的理想解决方案。

这个规划主要借鉴了 efluxeflux 文档地址: eluxjs.com/designed/mi…

我们看下 Monibuca Web 管理器的前端目录结构,如下图所示:

6.png

上图目录是以文件职能划分,功能模块作为次级分类,如果我们想做到下图这种能力

8.png

你会发现,是比较困难的,因为我们的功能是通过很多目录协作完成的。如果使用微模块的思想,那么这个问题就会得到很好的解决。

我们约定好路由和状态管理方案,把公共的依赖做成基座。这样就可以很好的做到业务模块的复用。也为后续桌面端和 Web 端共用业务模块打下坚实的技术基础。

类似下图:

10.png

stage 目录为基座,提供公共依赖。其他模块为业务模块。`

总结

至此,全文阐述了为 Monibuca 开源项目开发 Monibuca Web 管理器的方方面面,包含思考衡量、开发前、开发中、优化、未来规划等内容, 希望对读者有所帮助。

文章只在掘金、 github 和公众号上同步

版权声明:本文系我原创,未经许可,不可转载和二次创作。