GWT不同后端的反馈

Question

我需要重新设计一个现有的应用程序，这个应用的后端使用的是Pylons（Python），前端使用的是GWT。
在重新设计的过程中，我也可以更换后端系统。
我尝试了解各种后端系统（Java、Python等）的优缺点，但如果能得到社区的反馈，我会非常感激。

现有应用程序：

这个现有的应用程序是用GWT 1.5开发的（现在运行在2.1上），它是一个多主机页面的设置。
Pylons的MVC框架定义了一组控制器/主机页面，其中嵌入了GWT小部件（“经典网站”）。

数据存储在MySQL数据库中，后端通过SQLAlchemy/Elixir来访问这些数据。服务器和客户端之间的通信是通过RequestBuilder（使用JSON格式）来完成的。

这个应用程序并不是一个典型的商业应用，没有复杂的CRUD功能（比如事务、锁定等），也没有复杂的权限系统（虽然需要一个简单的访问控制列表）。

这个应用程序主要用于可视化科学数据（图表、表格）。客户端界面主要用于以只读模式显示数据。虽然可能有一些CRUD功能，但这并不是应用程序的主要方面。
只有一部分科学数据会传输到客户端界面，而这部分数据是从大型数据集中生成的。
现有的后端使用numpy/scipy从数据库或文件中读取数据，创建矩阵并进行过滤。
访问或使用这个应用程序的用户数量相对较少，但每个用户/请求对后端的负担很大，因为它需要读取和过滤大型数据集。

新系统的要求：

我想从多主机页面的设置转向MVP架构（一个单一的主机页面）。
所以后端只提供一个主机页面，并作为AJAX调用的数据源。
数据仍然会存储在关系数据库中（使用PostgreSQL代替MySQL）。
会有一个简单的访问控制列表（定义谁可以看到什么类型的数据），可能会有一些CRUD功能（但这不是优先考虑的）。
数据集的大小会增加，因此后端的负担可能会更重。虽然并不会有很多并发请求，但少数请求需要后端快速处理。后端服务器的硬件（内存和CPU）不是问题。

可能的后端解决方案：

Python（SQLAlchemy、Pylons或Django）：

优点：

• 快速原型开发。
• 可以重用现有应用程序的部分。
• 使用numpy/scipy处理大型数据集。

缺点：

• 弱类型语言 -> 调试可能比较麻烦。
• 服务器/客户端通信（JSON解析或使用第三方库）。
• Python的全局解释器锁 -> 并发请求的扩展性？
• 服务器语言（Python）与客户端语言（Java）不一致。

---

Java（Hibernate/JPA、Spring等）：

优点：

• 客户端和服务器使用同一种语言（Java）。
• 调试“更简单”。
• 服务器/客户端通信（RequestFactory、RPC）更容易实现。
• 性能好，支持多线程等。
• 可以传输对象图（RequestFactory）。
• CRUD功能“容易”实现。
• 多层架构（功能丰富）。

缺点：

• 多层架构（复杂，需要大量配置）。
• 处理数组/矩阵（不确定Java中是否有类似numpy/scipy的库）。
• 并不是所有Java Web应用程序层/框架的功能都被使用（可能过于复杂？）。

我没有提到其他后端系统（如RoR等），因为我认为这两个系统是我用例中最可行的选择。
说实话，我对Java并不陌生，但对Java Web应用程序框架相对较新。不过我对Pylons比较熟悉，但在新的设置中，Pylons的特性（MVC、模板）可能不会被广泛使用，因为它可能只作为AJAX后端。

如果我选择Java后端，我需要决定是做一个RESTful服务（明确分离客户端和服务器）还是使用RequestFactory（更紧密的耦合）。没有特定的“RESTful”要求。如果使用Python后端，我可能会选择RESTful后端（因为我必须处理客户端/服务器之间的通信）。

虽然主要是科学数据会被显示（不属于任何领域对象图），但相关的元数据也会在客户端显示（这会倾向于使用RequestFactory）。
如果使用Python，我可以重用用于加载和过滤科学数据的代码。
如果使用Java，我就需要重新实现这一部分。

这两种后端系统都有各自的优缺点。
我会很感激任何进一步的反馈。也许有人对这两种后端系统或这个用例有经验。

提前谢谢大家！

Answer 1

我们以前也遇到过类似的问题。我参与设计和搭建了一个系统，前端用的是GWT，后端用的是Java（Spring和Hibernate）。我们的一些其他相关系统是用Python和Ruby开发的，所以我们有这方面的经验，也出现了和你一样的问题。

我们最终选择了Java，主要是为了整个技术栈使用同一种语言。因为同一组人同时在客户端和服务器端工作，使用同一种语言可以减少在客户端和服务器代码之间切换时的困扰（比如调试的时候）。回头看，我觉得我们当时的选择是对的，这个决定很不错。

我们使用了RPC，正如你自己提到的，这确实让客户端和服务器之间的通信实现变得简单。不过，我不能说我特别喜欢它。相比之下，REST加JSON感觉更合适，至少能让服务器和客户端之间的耦合度更低。我想你需要根据未来是否可能需要独立重新实现客户端或服务器来做决定。如果这种可能性不大，我建议遵循KISS原则，在这种特定情况下选择RPC，这样会更简单。

关于你提到的Java的缺点，我在原则上是同意的（我自己更喜欢Ruby on Rails），但在细节上我不太同意。我认为多层架构和配置并不是问题——现在的Spring和Hibernate都很简单。在我看来，在这个项目中使用Java作为客户端和服务器的语言，优势大于使用Python的相对简单性，而且你还会在接口上引入复杂性（比如使用REST而不是原生的RPC）。

至于Numpy/Scipy和Java的替代品，我无法评论，因为我没有这方面的经验。