Appearance
架构设计
架构设计
我们需要什么样的搭建能力
根据前面章节的介绍,我们已经大致清楚了可视化搭建所涉及的相关领域和方向,本小册接下来核心要介绍的是最常见也是用途最广的方向:基于业务功能的 h5 的可视化搭建场景。下面我们不费周章直接进入主题:我们所做的可视化搭建体系是面向产品和运营,对于这些人群大部分场景的业务诉求的出发点基本上都是:我有一个想法(玩法),我需要一个页面来快速支持的想法。同时也支持我不断的调整我的运营策略。如果不能快速支撑我的想法,我希望未来我的想法可以被复用。
为了满足业务诉求,我们构思出来的核心流程应该是类似这样的:
根据上面的核心流程,我们需要抽象一下要实现的具体能力如下:
- 需要有丰富的模板、组件玩法满足各种业务场景
- 需要有易用的可视化编辑器,所见即所得
- 需要有页面发布能力,支持编辑后页面随时发布上线
- 最重要的是稳定性,保障线上项目安全稳定运行
我们应该怎么设计
1. 需要有丰富的模板、组件玩法满足各种业务场景
之前笔者自己写过一个介绍关于可视化搭建系列的文章:厌倦了写活动页?快来撸一个页面生成器吧! 也实现了一个粗糙的 Demo 但其中一个很大的问题就是没有将组件和模板能力抽象,完全写死在编辑器中,没有和编辑器解耦。如何实现“丰富”这个能力将会是一个巨大的困境。
所以我们需要:
- 编辑系统和组件解偶,组件只需要遵循编辑系统的组织约定, 其具体开发过程和承载的逻辑与编辑系统无关, 支持自由拓展页面组件.
- 编辑系统与模板采用的前端框架解偶, 在遵循编辑系统约定下, 可以选择不同的前端框架.
2. 需要有易用的可视化编辑器,所见即所得
要解决这个问题,回归到可视化编辑器的本质是对页面可变的数据编辑,不同组件,不同模板反映到可视化编辑器上也就是不同的配置项,所以也就需要对不同页面、不同区块定义各自配置数据的数据结构和字段类型。那么如何来描述数据结构和类型呢?JSON Schema 是一个不错的选择,如 form-render:
3. 需要有页面发布能力,支持编辑后页面随时发布上线
页面发布能力则需要我们对运营后台编辑数据进行可视化表达。通过 page = fn(view, data)
这样的模式来编译出最终的页面。为了可以对外投放,我们又需要对页面进行发布操作。发布动作如果公司内部有自己的发布系统,我们可以通过对接自己内部的发布系统进行页面发布工作。
4. 最重要的是稳定性,保障线上项目安全稳定运行
万事俱备,只欠东风。所有的准备工作完成之后,就差最后一哆嗦,如果发布的页面出了线上问题,可能我们之前的努力就白费了。所以我们要设计一套完善的线上页面稳定性机制以及相关的应急方案。 页面我们可控的就是模板和组件,所以我们可以从这2个方面入手来设计稳定性方案:
总结
基于以上诉求,我们可以抽象化为下面的这样架构:
上面我们是针对大多数通用业务场景进行的架构设计,经过上面的介绍是不是已经迫不及待的想进入可视化搭建的世界一探究竟?下来小册会由点及面的为大家介绍如何实现上述体系的可视化搭建体系。