Hi Davide,
Let me first explain why we created separate frontend / backend (or web client / middleware) components in CUBA. From the very beginning to version 6, CUBA allowed developers to create both web and desktop user interfaces from the same code base. This was done by rendering the web UI using Vaadin and the desktop UI using Java Swing. This decision was made a long time ago when we believed that the desktop environment was often more suited to enterprise applications we were building.
Since the desktop environment is naturally separate from the application server, we decided that the web application should also be separated to ensure that application code functions in the same manner. This approach is used, for example, in our Sherlock product.
Although separating the UI and business logic layers into separate processes provided some benefits in terms of deployment and scalability for larger applications, it has also complicated development and impacted performance for simpler projects.
Over time, we reconsidered the need for a desktop client, and in version 7, along with the change to the screen API, we abandoned the desktop solution. BTW we didn’t encounter any dissatisfaction from users, so perhaps this was the right decision.
In CUBA version 7, the division between clients and middleware lost the major part of its significance and became doubtful. Later, in Jmix, we decided it was time to simplify the architecture and get rid of this artificial complexity.
We are currently working on improved support for DTO entities in Jmix apps, which should help in creating separate web apps connected to backend apps via a REST API. This will not be as straightforward as in CUBA’s client/middleware solution, and will require more effort to implement. However, on the other hand, it will be much more flexible and manageable.
Regards,
Konstantin
