java - 对GWT的不同后端的反馈

Question

我必须重新设计一个在后端使用Pylons(Python)在前端使用GWT的现有应用程序。
在重新设计的过程中，我还可以更改后端系统。
我试图阅读各种后端系统(Java，Python等)的优缺点，但是我很感谢社区提供的反馈。

现有应用程序:

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

数据存储在MySQL数据库中，并由后端使用SQLAlchemy / Elixir访问。服务器/客户端通信通过RequestBuilder(JSON)完成。

该应用程序不是具有复杂CRUD功能(事务，锁定等)或复杂权限系统(需要简单的ACL)的典型业务，如应用程序。

该应用程序用于科学数据的可视化(图表，表格)。客户端界面主要用于以只读模式显示数据。可能有一些CRUD功能，但这不是应用程序的主要方面。
仅科学数据的一个子集将被传输到客户端界面，但是该子集是从大型数据集中生成的。
现有后端使用numpy / scipy从db /文件中读取数据，创建矩阵并对其进行过滤。
访问或使用该应用程序的用户数量相对较少，但是每个用户/请求的后端负担非常高，因为它必须读取和过滤大型数据集。

新系统要求:

我想从多主机页面设置转移到MVP体系结构(一个主机页面)。
因此，后端仅服务于一个主页，并充当AJAX调用的数据源。
数据仍将存储在关系数据库(PostgreSQL而不是MySQL)中。
将有一个简单的ACL(定义谁可以看到什么样的数据)，也许还有一些CRUD功能(但这不是优先事项)。
数据集的大小将增加，因此后端的负担可能会更高。并发请求不会很多，但是少数几个必须由后端快速处理。后端服务器的硬件(RAM和CPU)不是问题。

可能的后端解决方案:

Python(SQLAlchemy，Pylons或Django):

优势:

快速原型制作。

重新使用现有应用程序

的部分

用于处理大型数据集的Numpy / Scipy。

缺点:

弱类型的语言->调试可能很痛苦

服务器/客户端通信(JSON解析或使用第3方库)。

Python GIL->扩展并发请求？

服务器语言(python)<>客户端语言(java)

Java(Hibernate / JPA，Spring等)

优势:

客户端和服务器(Java)的一种语言

“更容易”进行调试。

服务器/客户端通信(RequestFactory，RPC)实现器。

性能，多线程等

可以传输对象图(RequestFactory)。

CRUD“容易”实现

Multitear体系结构(功能)

缺点:

Multitear体系结构(复杂性，需要大量配置)

处理数组/矩阵(不确定Java中是否有numpy / scipy的垂饰)。

并非使用Java Web应用程序层/框架的所有功能(过度杀伤力？)。

我没有提到任何其他后端系统(RoR等)，因为我认为这两个系统是我的用例中最可行的系统。
老实说，我对Java并不陌生，但是对Java Web应用程序框架却相对陌生。我知道围绕Pylons的方式，尽管在新设置中不会使用很多Pylons功能(MVC，模板)，因为它可能仅用作AJAX后端。

如果我使用Java后端，则必须决定是执行RESTful服务(显然将客户端与服务器分离)还是使用RequestFactory(更紧密的耦合)。对于“RESTfulness”没有特殊要求。如果是Python后端，我可能会使用RESTful后端(因为无论如何，我必须照顾客户端/服务器的通信)。

尽管将主要显示科学数据(而不是任何域对象图的一部分)，但相关的元数据也将显示在客户端上(这将有利于RequestFactory)。
如果是python，我可以重复使用用于加载和过滤科学数据的代码。
如果是Java，则必须重新实现这一部分。

两种后端系统都有其优点和缺点。
感谢您提供任何进一步的反馈。
也许有人对后端和/或用例都有经验。

提前致谢

Answer 1

过去我们有同样的困境。
我参与了设计和构建具有GWT前端和Java(Spring，Hibernate)后端的系统的工作。我们的其他一些(相关)系统是用Python和Ruby构建的，因此专业知识就在那里，并且像您一样提出了一个问题。

我们主要决定使用Java，因此可以在整个堆栈中使用一种语言。由于相同的人同时在客户端和服务器端工作，因此使用单一语言工作可以减少从客户端代码到服务器代码(例如，调试时)进行上下文切换的需要。事后看来，我认为我们被证明是正确的，这是一个很好的决定。

我们使用了RPC，正如您自己提到的那样，它无疑简化了c / s通信的实现。我不能说我很喜欢。 REST + JSON感觉更正确，至少至少可以在服务器和客户端之间建立更好的解耦。我猜您将不得不基于是否期望将来将来需要重新实现客户端或服务器来做出决定。如果不太可能，我会采用KISS原则，因此采用RPC，这会使它在这种特定情况下保持简单。

关于您提到的Java的缺点，我倾向于在原理(我更喜欢RoR自己)上达成共识，但在细节上不同意。 IMO并不是多层结构和配置体系结构真正的问题-如今，Spring和Hibernate已经足够简单了。 IMO在该项目中跨客户端和服务器使用Java的优势胜过使用python的相对简便性，此外，您还将在接口中引入复杂性(即通过REST与本机RPC进行比较)。

我无法评论Numpy / Scipy和任何Java替代方案。我在那里没有经验。