认识前端数据治理

本文探讨了前端开发中以功能和业务为导向的区别,强调了数据治理的重要性,特别是准确性和实时性在业务系统中的角色。介绍了适合不同场景的数据上报方式,如image、ajax和beacon,并根据数据量和需求选择合适的上报策略。
摘要由CSDN通过智能技术生成

开发人员聚焦“功能”,简单来说,是对照着交互稿或设计稿,根据需求口述实现功能为主。显然,以功能为导向的前端开发和以业务为导向的前端开发是不同的。前者关注快速实现,快速迭代,满足用户需要,提升用户体验,多面向 toC 产品。而后者关注准确性,稳定性,满足客户需要,保证逻辑没有丝毫差错,多面向 toB 产品,甚至是内部系统。业务开发也讲究快速迭代,但是和面向C端用户的产品迭代不同。业务开发也存在随机突发性的快速迭代。

业务系统开发的其他特性还包括“性能并不那么重要”、“多迭代并行”、“数据准确,业务逻辑准确更重要”、“功能可以先上,后续再优化”这些特性。比如,没必要强调“秒开”体验和高并发。只有当业务系统需要对接业务团队外部人员时,才需要提供一个能够承受特大流量的服务,但实际上,这种场景,相当于在业务系统的基础上,部署一个大众性产品服务,也就是基于B端产品的C端产品,理念上已经横跨了两个领域,不能因此而否定前面对 B 端产品的结论。

业务型产品和功能型产品的区分,前者是持续合作的企业级产品,后者是一锤子买卖的普众型产品。后者是利用自己的资源、体验吸引用户使用,搞各种增值服务策略,让用户掏钱。业务型产品的盈利能力和C端产品孰高孰低,在产业互联网时代尚无定论。

准确性和数据

前端数据治理的重要指标是准确性和数据。在业务系统中,一个数据集合包括数据值和其他元数据。

某接口返回的数据结构:

{
  data: [
    {
      key: 'some',
      value: 1111,
      data_type: 'int', // 数据本身的类型
      display_formatter: '2f', // 数据在当前接口用来展示的类型,表示展示的时候要体现2位小数
    }
  ]
}

而不单单是只有数据值:

/** 不好的数据结构 */
{
  data: {
    some: 1111,
    another: 222,
  }
}

在开始功能开发之前,需要建立一套准确的领域模型,将属性、操作、事件抽象为独立统一体,这样才能保证开发人员首先对业务有一定的理解和认知,然后才是业务流程、功能、交互的开发。

前端数据治理

在前端也存在复杂的业务数据管理问题。由于前端的数据不会自动产生,而是需要从服务器端拉取,所以,本质上,前端的数据全部是运行时的,虽然前端也可以采用一些持久化技术实现数据存储,但是总体而言,前端仍然是在动态地使用内存即时的消费来自其他来源的数据。

以React为例,从后端拉取的数据,往往需要转化为组件或应用的 state,再由 React 消费state,完成界面渲染和更新。中间处理数据的环节很多,保证数据的准确性极其关键。

前端数据的即时性、流动性、多态性,特别是在业务系统中既要求准确,又要求适应多变的需求,单纯靠数据管理是无法完成的。

数据治理是数据管理的高级阶段。即要满足不管 React 层面怎么实现,业务对象的内在关联永远保持,无论运行时状态怎么变化流动,都遵循着业务的逻辑描述,从数据的产生到消亡,都在按照某种约束运行而不会超出这个范围,同时数据质量、数据安全也因这种约束得以保障,即使出错,也有明确的告警,这就是数据治理。

“数据治理涵盖了从前端业务系统、后端业务数据库再到业务终端的数据分析,从源头到终端再回到源头,形成的一个闭环负反馈系统。“

前端数据治理是一个狭义的概念,它虽然会涉及和后端的交互,但不应该侵入后端,也不需要从系统整体层面去设计,而是需要站在前端本身角度,重新审视功能开发的惯性思维,找到一种适合不同场景下的前端开发方式。

数据上报方式梳理

image

通过将采集的数据拼接在图片请求的后面,向服务端请求一个 1*1 px 大小的图片(gif)实现的,设置它的 src 属性就可以发送数据。这种方式简单且天然可跨域,又兼容所有浏览器,没有阻塞问题,是目前比较受欢迎的前端数据上报方式。但由于是 get 请求,对上报的数据量有一定的限制,一般为 2~8 kb。代码示例如下:

/** 客户端 */
var img = new Image();
img.width = 1;
img.height = 1;
img.crossOrigin = "anonymous";
img.src = '/sa.gif?project=default&data=xxx';

/* 服务端 */
set('Access-Control-Allow-Origin', '*');

设置允许跨域也可以避免 canvas 会识别出资源的跨域问题而造成画布污染。

ajax

通过 XMLHttpRequest 的 send 方法以post的方式发送 data 给服务端,可以发送大量的数据,默认发送方式是异步,不会阻塞页面,但会占用一定的客户端资源,且需要特殊处理跨域限制。XMLHttpRequest 的跨域请求默认不携带 cookie。要允许跨域携带cookies,首先浏览器设置中,没有关闭第三方 cookie 功能,而且进行以下配置:

/** 客户端 */
xhr.credentials=true; // 默认值是 false

/** 服务端 */
set('Access-Control-Allow-Credentials', true)
//不能设为星号,必须指定明确的、与请求网页一致的域名。
set('Access-Control-Allow-Origin', getRequestHeader('origin'))

beacon

navigator.sendBeacon API,是指浏览器通过异步的 post 方式发送数据到服务端。具体使用方法如下:

/**
 * @params url:数据将要被发送到的网络地址
 *         data:将要发送的 ArrayBufferView、Blob、DOMString 或者 FormData  类型的数据
 * @Return {boolean} 用户代理是否成功把数据加入传输队列
 */
navigator.sendBeacon(url, data);

其特点很明显: 

  • 在浏览器空闲的时候(跳转、刷新、关闭页面时)异步发送数据,不影响页面诸如 JS、CSS Animation 等执行;
  • 页面在非加载状态下,也会异步发送数据,不阻塞页面刷新、跳转和卸载等操作;
  • 可以保证数据发送不易丢失,浏览器会对其进行调度以保证数据有效送达。
  • 能够被客户端优化发送,尤其在 Mobile 环境下,可以将 beacon 请求合并到其他请求上一起处理;
  • 不受跨域限制,浏览器兼容性较好,可以支持除 IE 之外的几乎所有浏览器。
  • 当数据是 65536 字符长度时,异步请求进入浏览器发送队列失败,代表数据大小是有限制,不一样的浏览器应该有所差异。
  • 缺陷是只能判断出是否放入浏览器任务队列,不能判断是否发送成功。

小结

综上,面对不同的场景,选择适合的方式发送上报数据:

  • 如果发送数据量较小,比如采集用户在 Web 页面的页面浏览、元素点击、视区停留等行为事件,采用 image 方式上报给服务端更合适;
  • 如果发送数据量较大,比如获取后端所有数据用于前端渲染,ajax 方式更合适;
  • 如果需要进行精确统计,比如点击支付按钮、视频播放时长、页面跳转或关闭等行为时,选择 beacon 方式能最大程度保证数据成功率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

薛定谔的猫96

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值