My personal CRUD story – or how I came to CUBA platform
In this article, Mario David reveals how he came to the CUBA platform and what are the benefits that he discovered in the learning process.
Over the years I stumbled on the same type of problems in different companies and different areas. From small shops to fairly large enterprises, there are some basic business processes that should be fulfilled. These business processes often walk hand in hand with entering data.
I first came across this kind of requirements in the world of renting goods. A company I worked for started to rent little diggers to private gardeners for a weekend. Obviously they wanted to schedule the lettings of the few diggers they had.
We started out with something like an Access DB to achieve our goal. As the business grew, the requirements on the software grew as well.
Going from a list of orders that showed the user which products have been rented on a given time frame (in a very bad way, I should point out), we wanted to achieve some kind of more advanced scheduling view. Because users have more than one location, a web-based software seems to make a little more sense. So I started my journey to PHP, a quite popular choice back then.
But what really got me wondering was the fact that I had to do the same kind of stuff over and over again. Apart from the actual important views (like the scheduling view mentioned above), there were a ton of views and CRUD things that had to be implemented as well. Normally nobody really cares about these screens.
While staying in the PHP world I really got to work with the “bare metal” stuff like HTML, PHP, PEAR, etc.
Scaffolding to the rescue
Fast forward a few years and CRUD projects later. Object orientation crossed my mind due to computer science studies mostly in form of Java. It felt like I was ready for the next big step. As most of us know, doing web-based software in Java is a pain, not a joy. So I looked around to get rid of the old PHP things I made in the past few years.
During that time the new kid on the block was Rails. The concepts for web applications that were introduced like CoC, database migrations etc. were pretty amazing —I thought. But one thing was an eye opener: scaffolding. To go from a model that defines the business object and generate full stack from DB definitions to HTML Forms as well as an “RESTful API” was pretty neat. It changed my view.
The general consensus in the software industry was and still is that these scaffolding mechanisms have to be treated with caution. One thing is that “it does not work for real applications”. Another statement that is often used is that “the resulting UI doesn’t fit our requirements”.
Scaffolding cannot solve all these problems, because the range is too broad. This is why the results of these scaffolding attempts end up with a CRUD interface for domain types that have certain limitations from a UI point of view as well from its functionality. Which is totally fine because the focus of these frameworks has never been on the scaffolding side of things.
“Domain specific” depends on the perspective
“Domain specific” is a pretty generic term. From the viewpoint of Java Servlets, Rails is absolutely domain specific, where the domain is “web-app with a relational database backend”. The same goes for the more general Spring MVC vs. the full stack Framework Grails, which is based on Spring (MVC). Still, Java Servlets are much more specific than using sockets.
A few months ago, I came across the CUBA platform via an article from Java Code Geeks. CUBA is primarily a commercial “framework” with the following slogan: “A high level Java framework for faster enterprise software development”.
At first glance, it appeared to be just another web framework. However, instead of creating all the subparts by itself, it uses a kind of meta-framework approach just like Grails does. The OR-Mapper is JPA (EclipseLink), Spring for DI, Vaadin as a UI Framework.
A new category in general purpose – domain specific dimension?
I soon realized that it was different from anything I’d seen before in the web development space.
The difference was that the authors of CUBA had chosen the “domain specific” path and focused on “enterprise software development.” With this focus is mind, the authors were able to be much more opinionated. Opinionated frameworks normally increase productivity if you follow their way of life (just like “The Rails way” in the Rails world). The same goes for the CUBA platform.
The phrase “rapid application development” really gets another meaning here. This is due to multiple reasons.
What makes it so special?
A domain model for a business application has a lot of entities as well as connections between them. This leads to an UI, where you have to create a lot of related entities in your actual workflow.
First of all, they get the basic stuff required for a business application completely right. CUBA creates a scaffolded UI that totally fulfills these needs. It is based on the different choices they made for the different styles of associations that two entities can have. A Many to One or One to One associations are represented via a PickerField, a Many to Many relationship creates a add / remove table for the association whereas a One to Many association will create a table within the detail view of the Entity that holds the One side.
With these simple, yet incredibly powerful tools, you can create a pretty complex domain model with a similar complex UI within minutes.
The second part is the generic filter solution. It feels a bit like the filter possibilities you’ll know from Excel with the additional feature that you can filter over associations of the entity the table is based on. This is pretty amazing and removes the need for a lot of custom filter programming that would have been created otherwise manually by the developer.
Next, there is a full-blown security subsystem. It is based on an ACL approach, which lets you as a user creates users, groups, roles that let you slice your application on a view, entity (+ attribute) as well as entity instance levels. Creating (create in this context just means: use the software) an app that fulfills the following requirements is not a problem:
- Managers in NY see all customers in NY
- Sales in NY see customers in NY. Customers in SF are shown with just the properties “name” and “city”, where only “name” can be edited.
- Managers in TX (Headquarter) see all customers from all locations, but cannot edit them.
With comprehensive UI to manage these things, there is very little need to implement a home-grown security solution. This feature list could go on and on.
The essence of this finding
The aspects that differentiate CUBA from other programming frameworks are the different “platform” features that were added on top of these technical frameworks. These things allow the programmer to focus on the business problem. This is principally a good thing, although it is a truism.
The problem is that this is a hard thing to imagine as a programmer. We, the techies, love poking around with NTLM authentication, fiddling around until we get the perfect user interface for entering our order instances, or creating a hypermedia driven RESTful HTTP Interface for our API. We want to create things.
However, we can look at it from another angle too. As we probably know already from Isaac Newton, Scott Hanselman or Sheldon Cooper:
We are all standing on the shoulders of giants
This is especially true in the software development space. Obviously this general piece of advice has to be treated with caution. There are various good reasons to develop software using C as well as Plain Java Servlets or CUBA.
When you want to create typical enterprise apps (nail) and there comes this CUBA (hammer) – it’s a very good fit.
I absolutely encourage you to check out CUBA and especially the different online demos.
This article first appeared on Road to CUBA and beyond.