GWT不同后端的反馈(Feedback on different backends for GWT)

GWT不同后端的反馈(Feedback on different backends for GWT)

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

现有应用程序：

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

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

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

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

新系统的要求：

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

可能的后端解决方案：

Python（SQLAlchemy，Pylons或Django）：

优点：

快速原型。 重新使用现有应用程序的某些部分 Numpy / Scipy用于处理大型数据集。

缺点：

弱类型语言 - >调试可能会很痛苦 服务器/客户端通信（JSON解析或使用第三方库）。 Python的GIL - >与并发请求缩放？ 服务器语言（python）<>客户端语言（java）

---

Java（Hibernate / JPA，Spring等）

优点：

用于客户端和服务器的一种语言（Java） “更容易”调试。 服务器/客户端通信（RequestFactory，RPC）易于实现。 性能，多线程等 对象图可以传输（RequestFactory）。 CRUD“轻松”实施 Multitear架构（功能）

缺点：

Multitear架构（复杂性，需要大量配置） 处理数组/矩阵（不确定在java中是否有吊挂/ scipy）。 并非所有使用的Java Web应用程序层/框架的所有功能（矫枉过正？）。

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

如果我使用Java后端，我必须决定是否执行RESTful服务（并明确将客户端与服务器分开）或使用RequestFactory（更紧密的耦合）。 对“RESTfulness”没有具体要求。 在Python后端的情况下，我可能会使用RESTful后端（因为我必须照顾客户端/服务器通信）。

虽然主要显示科学数据（不是任何域对象图的一部分），但相关的元数据将显示在客户端上（这将有利于RequestFactory）。 在python的情况下，我可以重新使用用于加载和过滤科学数据的代码。 在Java的情况下，我将不得不重新实现这个部分。

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

提前致谢

I have to re-design an existing application which uses Pylons (Python) on the backend and GWT on the frontend. In the course of this re-design I can also change the backend system. I tried to read up on the advantages and disadvantages of various backend systems (Java, Python, etc) but I would be thankful for some feedback from the community.

Existing application:

The existing application was developed with GWT 1.5 (runs now on 2.1) and is a multi-host-page setup. The Pylons MVC framework defines a set of controllers/host pages in which GWT widgets are embedded ("classical website").

Data is stored in a MySQL database and accessed by the backend with SQLAlchemy/Elixir. Server/client communication is done with RequestBuilder (JSON).

The application is not a typical business like application with complex CRUD functionality (transactions, locking, etc) or sophisticated permission system (tough a simple ACL is required).

The application is used for visualization (charts, tables) of scientific data. The client interface is primarily used to display data in read-only mode. There might be some CRUD functionality but it's not the main aspect of the app. Only a subset of the scientific data is going to be transfered to the client interface but this subset is generated out of large datasets. The existing backend uses numpy/scipy to read data from db/files, create matrices and filter them. The numbers of users accessing or using the app is relatively small, but the burden on the backend for each user/request is pretty high because it has to read and filter large datasets.

Requirements for the new system:

I want to move away from the multi-host-page setup to the MVP architecture (one single host page). So the backend only serves one host page and acts as data source for AJAX calls. Data will be still stored in a relational database (PostgreSQL instead of MySQL). There will be a simple ACL (defines who can see what kind of data) and maybe some CRUD functionality (but it's not a priority). The size of the datasets is going to increase, so the burden on the backend is probably going to be higher. There won't be many concurrent requests but the few ones have to be handled by the backend quickly. Hardware (RAM and CPU) for the backend server is not an issue.

Possible backend solutions:

Python (SQLAlchemy, Pylons or Django):

Advantages:

Rapid prototyping. Re-Use of parts of the existing application Numpy/Scipy for handling large datasets.

Disadvantages:

Weakly typed language -> debugging can be painful Server/Client communication (JSON parsing or using 3rd party libraries). Python GIL -> scaling with concurrent requests ? Server language (python) <> client language (java)

---

Java (Hibernate/JPA, Spring, etc)

Advantages:

One language for both client and server (Java) "Easier" to debug. Server/Client communication (RequestFactory, RPC) easer to implement. Performance, multi-threading, etc Object graph can be transfered (RequestFactory). CRUD "easy" to implement Multitear architecture (features)

Disadvantages:

Multitear architecture (complexity,requires a lot of configuration) Handling of arrays/matrices (not sure if there is a pendant to numpy/scipy in java). Not all features of the Java web application layers/frameworks used (overkill?).

I didn't mention any other backend systems (RoR, etc) because I think these two systems are the most viable ones for my use case. To be honest I am not new to Java but relatively new to Java web application frameworks. I know my way around Pylons though in the new setup not much of the Pylons features (MVC, templates) will be used because it probably only serves as AJAX backend.

If I go with a Java backend I have to decide whether to do a RESTful service (and clearly separate client from server) or use RequestFactory (tighter coupling). There is no specific requirement for "RESTfulness". In case of a Python backend I would probably go with a RESTful backend (as I have to take care of client/server communication anyways).

Although mainly scientific data is going to be displayed (not part of any Domain Object Graph) also related metadata is going to be displayed on the client (this would favor RequestFactory). In case of python I can re-use code which was used for loading and filtering of the scientific data. In case of Java I would have to re-implement this part.

Both backend-systems have its advantages and disadvantages. I would be thankful for any further feedback. Maybe somebody has experience with both backend and/or with that use case.

thanks in advance

最满意答案

我们过去也有同样的困境。 我曾参与设计和构建一个具有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替代品发表评论。 我没有经验。

We had the same dilemma in the past. I was involved in designing and building a system that had a GWT frontend and Java (Spring, Hibernate) backend. Some of our other (related) systems were built in Python and Ruby, so the expertise was there, and a question just like yours came up.

We decided on Java mainly so we could use a single language for the entire stack. Since the same people worked on both the client and server side, working in a single language reduced the need to context-switch when moving from client to server code (e.g. when debugging). In hindsight I feel that we were proven right and that that was a good decision.

We used RPC, which as you mentioned yourself definitely eased the implementation of c/s communication. I can't say that I liked it much though. REST + JSON feels more right, and at the very least creates better decoupling between server and client. I guess you'll have to decide based on whether you expect you might need to re-implement either client or server independently in the future. If that's unlikely, I'd go with the KISS principle and thus with RPC which keeps it simple in this specific case.

Regarding the disadvantages for Java that you mention, I tend to agree on the principle (I prefer RoR myself), but not on the details. The multitier and configuration architecture isn't really a problem IMO - Spring and Hibernate are simple enough nowadays. IMO the advantage of using Java across client and server in this project trumps the relative ease of using python, plus you'll be introducing complexities in the interface (i.e. by doing REST vs the native RPC).

I can't comment on Numpy/Scipy and any Java alternatives. I've no experience there.