CUBA Platform evaluation

Ideas
#1

Good afternoon,

I am looking at the documentation and sample applications of CUBA platform and I am really very impressed about the functionalities provided by the platform.

I would like to share some considerations about CUBA platform and have some opinion from the community.

I work in a small software house company where we develop custom applications that are mainly database oriented. In the last years we developed an internal development frawework that we used and are currently using for many new projects. Our framework is mainly a glue that puts together GWT, Sencha GXT and Hibernate to help the developers to write their applications hiding most of the details about database interaction, binding lists to the grids, records to the forms, filling combo-boxes, giving some CRUD facilities and some application infrastructure.

Looking at CUBA, I could say it is a supercharged version of our framework.

At the moment we are facing the problem of maintaining the latest versions of the libraries, in particular GXT: we are stuck on version 2 because from version 2 to version 3 a big refactoring has been made and we did not upgrade and now with version 5 a new major refactoring is announced. For the development of mobile applications we used Java native or IONIC.

For this reason we are looking at some possible substitutions, something that can be used for Web applications targeted to desktop browsers and mobile browsers and possibly something that gives the possibility to package native Apps. Another requirement is the longevity of the platform and the possibility to upgrade all the preexisting applications with a minimum effort, i.e. to be able to continuously update the applications simply upgrading the version of the platform (or with small adjustments to upgrade).

CUBA seems to fit very well for all our needs.

What I like about CUBA is the fact that there is an abstraction between the application logic (I mean business logic but also view/controller logic) and the final implementation of the user interface, if I understand correctly the developer does not (normally) invoke directly Vaadin UI objects. This makes possible to switch in the future the UI framework without having a big impact on each application you developed during the years, the big impact should be relegated only internally in the platform. For example I see that there is just now the possibility to use also polymer to develop the UI and this is great because you can share part of the business logic and serve some functionalities also to mobile devices (perhaps you can also use cordova to pack everything as native App).

But this advantage can have as counterpart the fact that not every feature of the UI framework is visible through CUBA so it is not usable. The same problem arises when a new release of the UI framework is available. For example, I suppose there are some plans to migrate the platform to Vaadin 8.

Another problem could be the fact that there are many Vaadin developers that know how to develop directly in Vaadin but not how to develop in CUBA.

About the polymer interface, perhaps the GWT polymer elements could be a good option to be able to develop everything in Java and not also in Javascript / Typescript.

Thanks in advance for the comments,

Marco.

#2

Hi Marco,

i will give my two cents on certain topics hoping that it will help you:

> This makes possible to switch in the future the UI framework without having a big impact on each application you developed during the years, the big impact should be relegated only internally in the platform.

I would argue: yes and no. Yes, because almost any code of the CUBA screens code (of the application developer) does not interact directly with the Vaadin APIs (except the code that intentionally uses vaadin directly to use direct addons etc). So you are right.

On the other hand though, Vaadin is a represents a certain category of web UI frameworks. It might be possible to replace Vaadin with something like GWT other similar frameworks, but probably not to a framework that has a different interaction model (like plain html pages). So there are definitively edges on that from (which are not at all cuba specific by any means).

I would assume a Vaadin major version change (like 7–>8) that it would not trigger the app developers to switch all of its CUBA UI code. Probably there are some changes that would bubble up to the CUBA UI APIs but certainly not the majority of it.
There was a major switch from CUBA 5.6 to 6.0 which replaced the OR-Mapper from Open JPA to EclipseLink. Although there is another API in between (JPA) which absorbs the shock additionally, it is definitively something that performs in a same league.

> Another problem could be the fact that there are many Vaadin developers that know how to develop directly in Vaadin but not how to develop in CUBA.

This is true, and will probably always be the case with higher level frameworks and lower layer frameworks. In this particular case, what CUBAs UI brings to the table is the possibility the declarative definition of a user interface (via XML). So this will probably be new to those developers. But the Java API in the UI is basically the same (from a 10’000 feet view) because, well - CUBAs UI APIs were built on top of using Vaadin…

Last, one could ask how much encapsulation from frameworks is needed at all. I think at some point it is totally good and necessary to choose a particular framework.

> About the polymer interface, perhaps the GWT polymer elements could be a good option to be able to develop everything in Java and not also in Javascript / Typescript.

I think that might be technically possible (probably with the vaadin web components as well) but i think that misses one of the main points of the polymer UI (at least as i understand it). Above you mentioned that there are more Vaadin developers as CUBA developers. This is definitively true. But what is also true is that there are more Javascript devs then Vaadin devs. Probably there are even more JS devs than there are Java devs. So i think the one main point is to open the platfrom from a Java targeted framework to a more general framework that will encourage a whole lot more people to work with it.

One other main point of the polymer UI is that the Vaadin development approach with “everything in Java”, especially the HTML based UI with Javascript is somewhat controversial. I think the majority of the software industry as a whole has learned and acknowledged that instead of hiding away the details of the web from the developer (which is basically the approach that ASP.net web forms, JSF, GWT and Vaadin implement) it is better to actively embrace it. This is where the whole javascript framework explosion comes into play… Therefore the polymer UI is an approach to also embrace these technologies, while not alienating anyone.

So i hope i could help you with my opinion and you have a good start with the framework.

If you are interested in further information about different topics in CUBA land, i write a blog from time to time at road-to-cuba-and-beyond.com.

Bye
Mario

#3

Hi,

You are right that by providing the higher abstraction the platform simplifies migration of the application code to newer versions of frameworks. We already did it when upgraded from Vaadin 6 to 7 several years ago. All the burden was on the platform, applications migration was quite smooth. We were even keeping both versions of Vaadin for some time as options (developers could choose what version to use in the project) because with Vaadin 7 we had problems with performance on IE 8 which was the only accepted browser for some enterprise customers that time.

The upgrade to Vaadin 8 is on our roadmap, but the timeframe is not yet decided.

As for Polymer UI it’s not a replacement for Generic UI (which is in fact rendered also in desktop Swing app) and they are not interchangeable. However the business logic located on the middle tier is naturally shared between all clients.

Also, you are right that Polymer UI is an approach to mobile devices - we are now using Phonegap in our internal pilot project, so the integration with Phonegap will be released in the near future.