采纳答案成功!
向帮助你的同学说点啥吧!感谢那些助人为乐的人
老师,每次切换标签页或分类都会触发数据请求,会不会对后端服务器造成很大压力?有没有什么方法让后端服务器有数据更新就通知小程序前端,前端知道有新数据才重新发起数据请求?否则数据没有变化的话就不用再发起后端请求。谢谢
这个问题需要综合考虑下,没有绝对的解决方法,需要根据实际业务场景需求来决定。
首先,在生产环境中,后端提供的这种列表数据都是优先从缓存系统中读取的,而且分页请求这个数量是很有限的,一次请求一般也就10到20条,即便是百万日活的小程序,后端也能轻松驾驭,不用担心压力问题。
那么假如现在有这么一个场景,我们的小程序是按课程的实现方式实现的,然后后端说扛不住了,这时候咋办。
第一种,就像你说的,后端有更新了再通知小程序,我们再去拉取。这个在小程序里目前只能通过建立长链接监听后端的消息来实现,但是这个实现方法的成本代价对于列表数据请求场景来说是不合适的。因为长链接需要后端提供长链接监听,这里需要前后端配合实现。长链接的实现方式只有在对信息实时性要求非常高的场景才会使用,比如即时通信、监控、预警信息推送之类。一般这种业务列表内容是不会要求实时性那么高的,这个你可以在平时一些带有列表的 APP 里感受到,你不重新请求就不会有新数据,即便有,你也不会第一时间请求到(后端的缓存还没更新)。所以这里长链接的解决方案你需要考虑业务需求来做选择。
第二种,HTTP3 协议可以实现后端给前端发通知消息,但是目前小程序不支持 HTTP3 协议,这个可以了解下,如果在其他前端应用里有这个需求可以尝试应用下。
第三种,让后端提供一个可以查询列表是否有更新的接口,前端定期去请求这个接口,根据结果来决定要不要请求数据列表。这种方法只适合数据列表接口返回的数据会很大,我们要有针对性的去请求的情况才会用这种方式。
第四种,前端主动缓存列表信息,通过逻辑控制,比如切换标签时,从前端缓存里读,其他情况走网络请求。这种方法不是不行,只不过得代码复杂度问题,因为切换标签这个行为,有可能是第一次切换,也有可能是来回切切换,这个缓存的机制需要设计一下。当然这个也是综合考虑的,你觉得这样值得那就这么做。
非常感谢。我改用云开发搭建云函数和云数据库,感觉请求云数据库响应比较慢。
云开发有冷启动问题,第一次请求会慢点是正常的,如果一直都是那么慢,那要找找问题。
登录后可查看更多问答,登录/注册
千锤百炼的实践分享,成就你独当一面
1.2k 17
908 7
1.0k 3
821 1
1.0k 8