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

Question

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

这种类型的架构基本上包括：

• 瘦服务器，只是一个无头的api：

  • 处理安全问题

  • 处理核心业务逻辑

  • 提供数据持久性

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

  • 缓存数据，并可以离线使用

  • 具有gui-templating和渲染功能

  • 保存并处理非关键业务逻辑

然而，乍一看，这样的架构对于今天网络的运作方式不会很好：

1. 当javascript不可用时可怜或无法回退（现在有2％的用户代理，我是对的吗？）

   • 可访问性问题（我在这里有点无能为力）

   • SEO问题，cloacking是一个选项，但这意味着应该提供一些服务器端的html渲染，并使该内容相关可能是棘手的

我还缺少什么？ 您将采取哪种方法来解决这些问题？

Answer 1

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

这里REST服务器将响应HTTP请求（GET，POST，DELETE等）来执行持久性的CRUD操作，并且很可能是业务核心规则和安全性。

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

在此之上，UI层将使用HTML，AJAX或whathaveyou对客户进行实际演示。

这种方法的巨大优势是：

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

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

• 可以合理简单地为不同情况创建不同的UI，例如用于移动电话等的精简用户界面

缺点包括：

• 这是相对较新的，因此缺乏工具支持（特别是在Microsoft领域）

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

希望这有帮助，

Answer 2

• 它是JavaScript或Flex（最好使用JS）。在我看来，这些2％可以安全地被忽略
• 辅助功能 - Check this，它仍在进行中，但值得一看。
• 搜索引擎索引内容。您将编写一个专注于功能而非内容的应用程序。您可以拥有一个打开的普通html屏幕，该屏幕将被编入索引。