So, Jmix seems exciting for sure!
What is the recommendation, for a company in our position, about 20-40% through a conversion of a very large, commercial application from an ancient legacy language/environment to CUBA (or Jmix?)
Convert what we have converted to CUBA to Jmix and go forward, or keep forging ahead in CUBA? 5 years isn’t that long (our app began development in the mid-1980s…)
Some advice/recommendations would be good.
Hi @jon.craig,
As long as Generic UI is mostly the same and business logic is easily portable from CUBA to Jmix and these two parts are normally the largest ones, I would recommend following your current way of porting your app to CUBA. Since Jmix goes over the preview stage (possibly 2 quarter 2021) I would suggest starting R&D for migration of what you will have so far.
Hope this makes sense.
Regards,
Aleksey
Thanks for the answer, Aleksey.
There are a couple of concerns currently:
What would be the determining factor there? What would make a bit of logic not easily portable to Jmix from CUBA?
Also in the announcement blog post the changes to UI aren’t super clear. It makes it sound like the current “Generic UI” which is Vaadin-based is being thrown out in favor of ReactJS - all of our UI is in the “Generic UI” as that will work perfectly for our app - if that disappears in Jmix, we’re stuck, but if there’s a way to convert easily then not.
Good question.
As long as you use only documented API (DataManager, EntityManager, GUI screens API, REST, etc.) - your code will be very easy to migrate to Jmix.
What will probably need to be rewritten: screens extended from framework’s screens, overridden
framework’s beans, custom authentication.
Security will need to be configured from scratch.
So our intention is to provide compatibility of your application-level code (business logic, data access and UI). Your system-level code and configuration may require major rewriting.
Sorry for the confusion, this is definitely not the case. Generic UI is called Backoffice UI in Jmix and is even significantly improved comparing to CUBA. It will offer some new visual components: Responsive Grid Layout, Pagination, Tag Picker, new Generic Filter. At the same time, all old components are also present (some of them only in compatibility module), and screens API is not changed.
So it’s absolutely safe to continue developing in CUBA Generic UI and migrate to Jmix when it’s ready.
Regards,
Konstantin
Hello,
I would like to put some words here, maybe they will help.
So when talking about information systems, one tries to develop them and stabilize them by locking the combination of hardware, OS, databases, and applications.
Hardware choice is related mainly to finances and the organization’s capabilities - do you have your own server infrastructure, and people to maintain it, and pay for it, or you can outsource this to the cloud provider. Also, security considerations are present - do you need/like to keep your data within your organization, or you can entrust it to a 3rd party (cloud provider), encrypted or no it’s still 3rd party…
Database choice? Databases stay for 10-15 years once selected.
Operating system - usually 5 to 7 years before being too old to update - atm think about Ubunto 20.04 LTS , before the new LTS version, which will bring different libraries and the software run on it needs to be probably updated/recompiled/adapted.
Finally, the software technologies you choose to implement your applications with.
Haulmont says CUBA 7.2 will be supported for 5 years, for 5 more, pay.
5 years is the average frontend app lifecycle duration.
From that standpoint, I think you should be fine to continue and use CUBA 7.3 as long as it goes, 5 years. You are at 40%, what are you going to do, wait for 6 months until JMix is out and stable and then continue development? I don’t think you can wait, or should throw away what you have. Its standard mix of technologies, you even have source code - bonus is you can use CUBA generators and scaffolding to not waste time on tedious things, and also people that don’t know Java well can work with it. Add-on licenses are enabling unlimited distribution.
Currently, you are using what Haulmont now calls “Backoffice UI”, which is Java + Vadiin.
They say it will work as-is in JMix, plus some more components, but, if you extended these screens to make custom, it will not without a rewrite. Shouldn’t be too hard, especially if you separate business logic and user interface code.
Haulmont also says there will be also “Frontend UI” additional option, which is JavaScript - “React and TypeScript, working with the Java backend through the REST API.” IT is as they say, more scalable.
“Scaleable” is very important again with the first item, hardware - nowadays cloud providers will charge you by CPU usage, so you want software technologies with better performance, to pay less.
Also, such technologies (microservices, REST calls) are easier applied if your application needs to scale, for example, you will be adding additional Kubernetes containers as needed.
With JMix, now you have that option to choose if you need it. CUBA is mature as is now, and nothing should force you yet to switch to JMix, just because JMix exists.
Haulmont has a lot of software implementations around, using CUBA, and too many important customers, to whom they are responsible, just to throw it away.