In the developer's life it happens to change one framework to another. The article is exactly about this, it shows the impressions of an experienced RoR developer moving to CUBA Platform. What is similar and what is perpendicular, what is more productive and what is easier to understand - read more in the article!
Herby Raynaud, original post is here
Having spent the past 6 years or so working on Rails apps, I was both intrigued and somewhat terrified when I learned that in my new job I’d be coding mostly in Java and in particular using a little known application framework called CUBA. I worked as a Java developer several years ago at a previous job, so I was familiar enough with Java and quite liked it as a programming language. However, I always felt overwhelmed and bewildered by the pot-pourri of enterprise-y (and often convoluted) technologies such as EJB, J2EE, JMS, JMX, Struts, AWT, Swing, JSF, Spring, etc., that one had to know in order to be considered a competent Java developer or even to build a simple web app.
Later, when I discovered Ruby and Ruby on Rails, I felt like I was Dorothy stepping out of a bleak and barren Kansas landscape into the dazzling garden wonderland of Oz. It’s not hard to see why, when you consider that even as newbie Ruby developer I could create functional web application with Rails, literally in minutes, by simply executing the following eight command lines at a terminal.
Granted, this fictional sales app we just created above is pretty basic, the mere fact that I could get this far so easily did indeed seem like the work of a wizard. Frameworks such as Grails and Play, which are heavily influenced by Ruby on Rails, bring similar features to JVM languages.
It’s not easy to make true apples to apples comparison between CUBA and Rails (or Grails and Play for that matter) so I will limit the rest of this discussion to the area where these frameworks and specifically Rails overlap – namely rapidly building CRUD business applications.
Returning to the sales application we created above, here is where we are after all the commands have completed. There is a customer model with two string fields: name and email. There is an order model with an amount field and a foreign key reference to the customer model. There are database migration scripts that will create the customers and orders tables in the DB as well as RESTful routes to the customers and orders resources. Finally, the
generate scaffold command also generated basic CRUD templates for both customers and orders.
CUBA, as a self described “Java RAD framework for enterprise web applications” (note the scary E word), takes a different approach altogether to building applications. For starters, to be as productive as possible in CUBA, it’s a good idea to download and run a separate application called CUBA Studio. Though not required, it automates a lot of tasks like generating Java and XML boilerplate and updating spring and gradle config files. More importantly it includes the drag and drop GUI builder. Once Studio is up and running the steps to building an app are roughly the same:
- Create a new project
- Create the Customers entity
- Create the Orders entity
- Generate the database and tables
- Generate the Customers UI screens
- Generate the Orders UI screens
- Compile the Sales application
- Start the application
- Navigate to localhost:8080 in your browser
The big difference of course is that you’re interacting with the Studio UI to accomplish these tasks. Also, in the interest of keeping this post short, I’ve glossed over a handful of intermediate steps in the CUBA workflow such as adding fields to the customers and orders entities (models) and setting up associations between the two.
I’ve attached a couple of short videos from the CUBA core team that show the actual process of building the Sales app in detail.
Overall, the CUBA workflow requires more of a hands-on-keyboard approach at each step of the application setup, which makes it less efficient than the command line approach provided by Rails and other frameworks. Still, the process is fairly painless and, as we’ll see in a bit, the additional out-of-the-box features provided by CUBA more than compensate for the added overhead.
Going back once again to our Rails app, we see that it is functional but that it is not much more than a glorified wireframe at this point.
There’s no styling of the generated page templates, no navigation between customers and orders and products, no authentication or authorization, customers and orders are linked at the database and model levels but there is nothing at the user interface level that visually or even logically ties these two concepts together. These are all behaviors that we’d want to implement or configure before we consider showing our application to our end users.
The CUBA version, on the other hand, is in a near shippable state as can be seen from this screenshot below.
- Built-in UI theme
- Menu based navigation
- Built-in authentication and user management
- Built-in and flexible access control: CUBA allows both developers and authorized end users to restrict access to operations on entities, pages, and elements on pages based on roles and group membership – all from within the application.
- Automatic linking of associated entities in the UI (i.e you can lookup customers from the orders screen and and vice versa)
- Built-in and powerful search filters: users can create any number of filters on arbitrary combinations of fields (with potentially pre-populated values), save and share them with other users
- Raw data import and export capability for all tables
- Built-in Reporting
- System Profiler
- JMX console
- Drag and drop UI builder with data aware GUI widgets
The GUI builder alone more than makes up for the extra bit of work involved in setting up the application.
Obviously CUBA and Rails are very different frameworks. The purpose of this comparison between them is not to suggest that CUBA is a drop in alternative for Rails (or any of the other frameworks that I’ve mentioned above) or that CUBA is better than Rails or vice versa. My goal rather, is to demonstrate that for teams that are already invested in Java and need to build modern, dynamic, web-based business or enterprise applications – and do so relatively quickly – CUBA is a great choice. You get a lot of the ease of use of and productivity features provided by modern web frameworks like rails while avoiding the switching costs associated with switching to a new dev stack.
For our internal applications team here at Yieldmo, CUBA has been a game changer. We’ve been able to build applications in weeks that might have taken months. We’re in the process of migrating some internal applications written using technologies like React, Angular and Node.js. By using CUBA, we spend less time reinventing the wheel. We’ve even leveraged some of CUBA’s more advanced features to build our new flagship SAAS Engagement Management Platform (EMP™) product.
Of course there are some downsides. CUBA is still relatively unknown so it doesn’t have the huge open source community backing of more popular platforms. That being said, the core team and developer forums are great resources when you need help. CUBA is also an opinionated framework; as your application grows and your use cases expand you may find that there is your way and there is the CUBA way of implementing a feature. Experienced Java developers may have to unlearn some patterns and adopt new ones.
In the 10 months or so that I’ve been using CUBA I’ve been very pleasantly surprised by what the platform can do and look forward to learning more about it and seeing CUBA grow. I hope this post encourages you to do the same.