后台部分业务场景需要产品或运营配置JSON数据以供开发使用（实际业务场景后面会介绍），原始业务流程，非开发者（后面直接称为产品）把数据交给开发，然后开发再更新JSON数据。对于产品来说，直接接触JSON数据并不友好。首先，他们无法理解JSON；二是容易出错，影响现网数据。基于此，需要解决两个问题：如何让产品更友好的配置各种数据？如何减少数据错误？表单可能是一个可以接受的解决方案，带有标题和各种交互UI组件……这比让产品直接在MonacoEditor中编写JSON更好；表单本身也支持数据校验，是否必填，最大值最小值，数据格式，正则匹配...而对于表单这样的UI，react和vue都有很多基于JSONSchema的比较成熟的表单UI库，对于比如阿里开源的一站式中后端Form解决方案：form-render，基本具备上述功能，而且访问方便。优点通过表单UI完成数据配置的交互，更容易被非开发人员接受。开发者在配置JSONSchema时，可以根据各个字段的规范编辑校验逻辑，配置数据时可以直接检查是否有错（类似于typescript在编译时进行静态类型检查）。交互约束保护数据结构，防止滥用破坏数据结构导致在线数据出现问题。有效的保护数据安全，比如给产品提供一个Checkbox来勾选需要的数据，比让产品直接写数组要好很多。自定义表单组件（如form-renderwidgets），开发自定义表单组件，功能组件如：CDN图片上传裁剪组件，链接生成组件，数据预填组件（指先填写一些字段，再拉取）从后台抓取其他相关数据填写到表单中，比如输入一个用户的uin，组件会自动拉取这个uin相关的个人信息填写到表单中）功能后台提供了两种拉取方式：cdn和请求接口：CDNCDN速度比较好，服务器压力没那么大，可以缓存，但是更新会有延迟（需要刷新）。所以适合比较固定的数据。请求接口请求接口的速度有点慢，好在数据足够实时，可以支持半可配置数据。数据半配置是指后台接收到表单提交的数据后，对部分字段进行一层标准化处理。例如：现在我们需要每周的作者投票列表。产品填写或自动生成一些基础字段（如作者头像链接、昵称、描述等用户个人信息）后，需要实时更新。为该字段选择相应的标识选项（如票数），通知后台该字段需要后台取回并填写到数据中，才能返回给请求者。需要注意的是，选择对应标识选项的能力一般是通过一个widget来开发的，但是和数据预填充组件的区别在于这个widget主要是通知后台完成填充数据的相关逻辑，而不是直接在前端拉取数据。拉取的数据自动填入表单（比如上面提到的用户个人信息可以通过用户uin拉取）。前端数据列表页入口页区分测试环境和正式环境，可以通过域名或者其他方式区分。原型如下：topbar:formid:自动生成，作为获取数据的唯一标识（包括用于描述表单UI的JSONSchema，表单实际填写的数据等）Partstatus:Editing,Released,Deleted当前版本号创建时间Type:Form:填写生成的表单；默认：直接在MonacoEditor中填写JSON数据操作栏：Editschema：跳转到表单编辑页面，如果类型不是Form，则灰色不可用Editdata：表单页面或数据页面，取决于您选择创建方式删除：使数据失效历史版本：版本记录，版本回退，版本对比高亮显示，当前版本：以数据库数据为准，并通过与CDN链接的数据进行比较，判断CDN是否使用fr-更新表单编辑页面generator，支持手动导入导出JSONSchema。编辑生成的schema需要存储起来，以便下次编辑时直接显示表单UI，同时需要请求数据库数据，将数据回填到表单中。表单页面左侧为表单，通过表单id拉取对应的Schema，通过form-render渲染UI；右侧实时显示当前表单的JSON数据。当左侧的表单数据发生变化时，右侧的JSON数据会实时更新，并突出显示差异。它还支持JSON数据导入和导出。数据页基于MonacoEditor实现，适合开发者快速填写一些数据。总结本文主要介绍背景和功能。其实还有很多细节没有讲到，比如如何定义后台接口的数据结构，使其能够支持更通用的数据（比如JSONSchema也是使用同一个接口读写）read并写要求；后台服务是如何实现的，具体使用了哪些技术栈；平台的权限管理是如何实现的等细节。同时，也有很多问题值得思考，比如正式环境和测试环境的数据如何隔离；是否可以将数据预填组件换成formhook，更简洁易扩展；如何实现不同表单之间的数据联动等相关问题。以后会有其他文章来讨论这些细节和问题。
