Translate

前后端分离,网页开发和客户端开发的区别

1. B/S 架构 和 C/S 架构:

在移动互联网出现之前,有这两种架构:Browser/Server 和 Client/Server,后者需要安装客户端,相对更麻烦;前者只需要有浏览器就可以,所以一度认为 B/S 架构是更好的替代者。

前后端的分离为了更好的分担工作量,让两边可以同时进行工作


2. 网页开发和客户端开发的区别

网页开发迭代非常容易,但是客户端开发需要打包成新的安装包覆盖;

客户端编译语言,很多错误编译期就可以发现;网页是脚本语言



比较是否需要将backend从app中分离:

方案一:ios直接调用Firebase (不分离)
方案二:通过nodejs服务器调用Firebase(分离)

描述:

百万级流量,从安全 / 并发性能 / 成本 / 可扩展 等角度分析

方案一(不分离)

优点:

  性能更优:
  • 数据直接从 Firebase 到客户端,减少了网络中间环节(如服务器转发)。
  • Firebase 的实时数据库和 Firestore具备高扩展性,能够自动处理高并发。
  开发效率高:
  • 省去了中间服务器的开发、部署和维护。
  • Firebase SDK 提供了丰富的功能,便于快速开发。
  成本低:
  • 无需额外支付中间服务器的运行和维护费用。
  • Firebase 提供一定免费额度,可以降低初始运营成本。

缺点:

  安全性依赖规则:
  • 需要非常严谨地配置 Firebase 安全规则,否则可能导致数据泄漏或滥用。
  复杂逻辑难以处理:
  • 客户端只能进行简单的业务逻辑,复杂操作需要额外实现。
  客户端压力较大:
  • 如果需要处理大量数据,客户端可能需要下载较多数据,导致性能瓶颈。

方案二(分离)

优点:

  更高的安全性:
  • 客户端不直接访问 Firebase,数据库的访问完全受服务器控制。
  • 更容易隐藏敏感数据或业务逻辑。
  适合复杂逻辑:
  • 可以在服务器端实现复杂的业务规则、数据聚合和跨服务操作。
  • 方便与第三方服务(如支付、机器学习模型)集成。
  更好的数据流量控制:
  • 服务器可以缓存常用数据,减少直接对 Firebase 的请求频率。
  • 可以对客户端的请求进行限流或过滤,保护数据库。

缺点:

增加延迟:
  • 数据流需要经过中间服务器转发,增加了一定网络延迟。
开发和运维成本更高:
  • 需要开发、部署和维护中间服务器。
  • 对服务器的可用性和扩展性有更高要求。
服务器成本:
  • 高并发情况下,服务器的运行费用可能较高。

No comments:

Post a Comment