architecture - Web 应用程序中真正的客户端-服务器架构的陷阱？

Question

我一直在研究如何以真正的客户端-服务器方式构建 Web 应用程序。

这种类型的架构主要包括:

• 瘦服务器，仅仅是一个 headless 的 api:

  • 处理安全问题

  • 处理核心业务逻辑

  • 提供数据持久化

• 胖客户端，具有类似于桌面的设计:

  • 缓存数据，使离线使用成为可能

  • 具有图形用户界面模板和渲染功能

  • 持有和处理非关键业务逻辑

但是，乍一看，这样的架构与当今网络的运作方式并不协调:

1. 当 javascript 不可用时，回退效果很差或没有可能回退(如今 2% 的用户代理，对吗？)

   • 可访问性问题(我在这里有点无能)

   • 关注 SEO，伪装是一种选择，但这意味着应该提供一些服务器端 html 呈现，并且使内容相关可能很棘手

还有什么我想念的吗？ 您会采用哪种方法来解决这些问题？

Answer 1

REST 允许为 Web 应用程序和桌面应用程序轻松创建此类架构。

此处 REST 服务器将响应 HTTP 请求(GET、POST、DELETE 等)以执行 CRUD 操作以实现持久性，以及很可能的业务核心规则和安全性。

多个 REST 服务器可能会在较大的系统中使用“协调器”进行聚合，以处理事务等问题。

在此之上，UI 层将使用 HTML、AJAX 或其他方式向客户端进行实际演示。

这种方法的最大优点是:

• 它是可扩展的。 REST 持久层和协调层是无状态的，因此可以引入额外的服务器来解决更大的负载。

• 数据持久性、安全性和业务逻辑被巧妙地封装在 UI 之外。

• 可以合理简单地为不同情况创建不同的 UI，例如用于手机等的精简 UI。

缺点包括:

• 它相对较新，因此缺乏工具支持(尤其是在 Microsoft 领域)

• 大型系统的部署可能会变得复杂，因为可能存在很多服务相互依赖性

希望对您有所帮助，