Feedback on different servers for GWT

Question

I need to reverse engineer an existing application that uses Pylons (Python) on the server and GWT on the interface.
During this redesign, I can also change the backend system.
I tried to read about the advantages and disadvantages of various backend systems (Java, Python, etc.), but I would be grateful for some community feedback.

Existing application:

The existing application was developed using GWT 1.5 (now running in version 2.1) and is the configuration of several hosts.
The Pylons MVC framework defines the set of controllers / host pages into which the GWT widgets ("classic website") are embedded.

The data is stored in a MySQL database and access the server using SQLAlchemy / Elixir. Communication with the server / client is done using RequestBuilder (JSON).

The application is not a typical business application with complex CRUD functions (transactions, locking, etc.) or a complex permission system (requires a simple ACL).

The application is used to visualize (graphs, tables) scientific data. The client interface is mainly used for displaying data in read-only mode. There may be some CRUD functions, but this is not the main aspect of the application.
Only part of the scientific data will be transferred to the client interface, but this subset is created from large data sets.
The existing backend uses numpy / scipy to read data from db / files, create matrices and filter them.
The number of users accessing or using the application is relatively small, but the burden for the backend for each user / request is quite large, since it must read and filter large data sets.

Requirements for the new system:

I want to move away from configuring a multi-page page to the MVP architecture (one page with one host).
Thus, the backend only serves one host page and acts as a data source for AJAX calls.
Data will be stored in a relational database (PostgreSQL instead of MySQL). There will be a simple ACL (defines who can see what data) and, possibly, some CRUD functions (but this is not a priority).
The size of the data sets will increase, so the burden on the backend is likely to be higher. There will not be many simultaneous requests, but some of them must be quickly processed by the backend. The hardware (RAM and CPU) for the server server is not a problem.

Possible backend solutions:

Python (SQLAlchemy, Pylons or Django):

Benefits:

• Rapid prototyping.
• Reusing parts of an existing application
• Numpy / Scipy for processing large data sets.

Disadvantages:

• Weakly typed language -> debugging can be painful
• Communication with the server / client (JSON analysis or use of third-party libraries).
• Python GIL -> scaling with simultaneous requests?
• Server language (python) <> client language (java)

---

Java (Hibernate / JPA, Spring, etc.)

Benefits:

• One language for client and server (Java)
• Easier to debug.
• Access to the server / client interface (RequestFactory, RPC).
• Performance, multithreading, etc.
• The graph of objects can be passed (RequestFactory).
• CRUD is easy to implement
• Layered Architecture (Features)

Disadvantages:

• Layered architecture (complexity, requires a large configuration)
• Array / matrix handling (not sure if there is a pendant for numpy / scipy in java).
• Not all Java web application layer / framework functions are used (overkill?).

I did not mention any other backend systems (RoR, etc.) because I think that these two systems are the most viable for my use case. Honestly, I'm not new to Java, but relatively new to the Java web application framework. I know my way around Pylons, although most of the features of Pylons (MVC, templates) will not be used in the new setup, because it probably only serves as AJAX.

If I use the Java backend, I have to decide whether to do a RESTful service (and explicitly separate the client from the server) or use RequestFactory (a tighter connection). There is no special requirement for "RESTfulness". In the case of the Python backend, I would probably go with a RESTful backend (since I should always maintain client / server communications).

Although it will mainly display scientific data (and not part of any graph of domain objects), the client will also display related metadata (this will depend on RequestFactory).
In the case of python, I can reuse the code that was used to load and filter the scientific data.
In the case of Java, I would have to reimplement this part.

Both backend systems have their advantages and disadvantages. I would appreciate further feedback. Perhaps someone has experience with both the backend and / or with this use case.

early

Answer 1

We had the same dilemma in the past. I participated in the development and creation of a system with the interface of GWT and Java (Spring, Hibernate). Some of our other (related) systems were built on Python and Ruby, so the experience was there, and a question arose similar to yours.

We decided to use Java mainly so that we could use one language for the whole stack. Since the same people worked both on the client side and on the server side, working in the same language reduced the need to switch context when switching from client code to server (for example, during debugging). Looking back, I feel that we were right, and that was a good decision.

We used RPC, which, as you mentioned, definitely made it easier to implement c / s communications. I can’t say that I really liked it. REST + JSON feels more right and at least creates a better decoupling between server and client. I think you will have to decide based on whether you expect that in the future you may need to re-implement any client or server. If this is unlikely, I would go with the KISS principle and thus with RPC, which simplifies it in this particular case.

Regarding the flaws of Java that you mention, I tend to agree with the principle (I prefer RoR myself), but not in detail. Layered architecture and configuration is not really an IMO problem - Spring and Hibernate are pretty simple right now. The IMO advantage of using Java throughout the client and server in this project is superior to the relative ease of use of python, plus you will introduce complexities in the interface (i.e. Make REST and native RPC).

I cannot comment on Numpy / Scipy and any Java alternatives. I do not have experience.