{"id":475527,"date":"2026-04-11T12:04:44","date_gmt":"2026-04-11T12:04:44","guid":{"rendered":"https:\/\/savepearlharbor.com\/?p=475527"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=475527","title":{"rendered":"CUBA: Why It Saved My Hackathons and Killed My Production Projects"},"content":{"rendered":"<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<figure class=\"bordered full-width \"><img decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/274\/c00\/7ae\/274c007ae862fd176a222276c92afb30.png\" width=\"1080\" height=\"1080\" sizes=\"auto, (max-width: 780px) 100vw, 50vw\" srcset=\"https:\/\/habrastorage.org\/r\/w780\/getpro\/habr\/upload_files\/274\/c00\/7ae\/274c007ae862fd176a222276c92afb30.png 780w,&#10;       https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/274\/c00\/7ae\/274c007ae862fd176a222276c92afb30.png 781w\" loading=\"lazy\" decode=\"async\"\/><\/figure>\n<p>If you have ever done enterprise Java development, you have probably heard of CUBA Platform. And no \u2014 this is not about the Caribbean.<\/p>\n<p>CUBA is a full-stack Java framework for rapid development of business applications: CRM, document management, ERP-like systems, internal tools, and everything commonly called \u201centerprise.\u201d<\/p>\n<p>I worked with it in several hackathons and in a couple of real projects. And I have mixed feelings about it \u2014 that is exactly why I am writing this.<\/p>\n<h4>What CUBA Is and Why It Exists<\/h4>\n<p>CUBA is built on top of Spring Framework and a number of other technologies. Its philosophy is simple:<\/p>\n<blockquote>\n<p>Maximize the development speed of typical business applications by removing boilerplate.<\/p>\n<\/blockquote>\n<p>Out of the box, you get:<\/p>\n<ul>\n<li>\n<p>ORM via JPA<\/p>\n<\/li>\n<li>\n<p>a Vaadin-based UI framework<\/p>\n<\/li>\n<li>\n<p>auto-generated CRUD screens<\/p>\n<\/li>\n<li>\n<p>a roles and permissions system<\/p>\n<\/li>\n<li>\n<p>a report generator<\/p>\n<\/li>\n<li>\n<p>REST API<\/p>\n<\/li>\n<li>\n<p>a ready-to-use admin panel<\/p>\n<\/li>\n<\/ul>\n<p>In other words, the entire standard enterprise skeleton is already written for you. You only need to add business logic.<\/p>\n<h4>Why It Works: A Hackathon Case<\/h4>\n<p>In most hackathons I participated in, we used CUBA as a foundation. Why?<\/p>\n<p>Because it is incredibly fast.<\/p>\n<p>Here is a real-world scenario:<\/p>\n<ol>\n<li>\n<p>You create an entity (for example, <code>Order<\/code>, <code>Client<\/code>, <code>Product<\/code>)<\/p>\n<\/li>\n<li>\n<p>You click a couple of buttons in Studio<\/p>\n<\/li>\n<li>\n<p>You get a ready-made list screen, edit screen, validation, and a REST endpoint<\/p>\n<\/li>\n<\/ol>\n<p>All of this happens in minutes, not days.<\/p>\n<p>For a hackathon, this is a killer advantage. While other teams are configuring Spring Security and writing controllers, you already have a working prototype with UI, authorization, and reports.<\/p>\n<p>In practice, CUBA is a very powerful admin-panel generator with the ability to attach business logic. For MVPs, internal tools, and prototypes, it is one of the fastest approaches in the Java ecosystem.<\/p>\n<h4>Where the Problems Begin<\/h4>\n<p>And this is where things get more interesting.<\/p>\n<h3>1. Complexity Does Not Scale Well<\/h3>\n<p>While the project is small, everything is great. But as soon as you get more screens, more business logic, and more non-standard cases, maintainability starts to drop.<\/p>\n<p>The reason is that CUBA generates a lot of XML configuration. And when there is too much XML, maintaining it becomes a separate job.<\/p>\n<h3>2. \u201cClick-Driven Development\u201d Does Not Scale<\/h3>\n<p>A lot of things in CUBA are configured through Studio UI. It sounds convenient, but in practice:<\/p>\n<ul>\n<li>\n<p>the same changes must be repeated manually<\/p>\n<\/li>\n<li>\n<p>modifications are spread across dozens of XML files<\/p>\n<\/li>\n<li>\n<p>keeping consistency is difficult<\/p>\n<\/li>\n<\/ul>\n<p>A specific example: if you need to change one UI component across 10 forms, get ready to click through it manually 10 times. Automating this inside the CUBA ecosystem is extremely inconvenient.<\/p>\n<h3>3. \u201cEscape to Code\u201d and the Meaning of Abstractions<\/h3>\n<p>At some point, you realize that it is easier to just do it properly in code:<\/p>\n<pre><code>@Injectprivate DataManager dataManager;\/\/ Custom controller, custom logic...<\/code><div class=\"code-explainer\"><a href=\"https:\/\/sourcecraft.dev\/\" class=\"tm-button code-explainer__link\" style=\"visibility: hidden;\"><img style=\"width:87px;height:14px;object-fit:cover;object-position:left;\"\/><\/a><\/div><\/pre>\n<p>And yes \u2014 this is possible in CUBA: there is inheritance, custom controllers, and extension of standard screens. But then the usual thing happens: you are writing a normal backend again, only on top of someone else\u2019s abstractions.<\/p>\n<p>And then a fair question appears: why do all these layers exist in the first place?<\/p>\n<p>I do not have a comfortable answer. More precisely, I do, but it is not a pleasant one: those layers were useful at the beginning, and now you are forced to live with them.<\/p>\n<h3>4. Vendor Lock-In<\/h3>\n<p>This is the most serious problem. Once the project has grown:<\/p>\n<ul>\n<li>\n<p>the UI is tied to Vaadin through CUBA abstractions<\/p>\n<\/li>\n<li>\n<p>the business logic is written in the paradigm of CUBA services<\/p>\n<\/li>\n<li>\n<p>configs, roles, reports \u2014 everything lives inside the ecosystem<\/p>\n<\/li>\n<\/ul>\n<p>Migrating to something else is almost impossible. Rewriting it means starting from scratch.<\/p>\n<h3>5. Performance Under Load<\/h3>\n<p>CUBA adds abstraction layers on top of JPA, and that becomes noticeable as load grows:<\/p>\n<ul>\n<li>\n<p>it is hard to control the generated SQL<\/p>\n<\/li>\n<li>\n<p>it is difficult to optimize specific queries<\/p>\n<\/li>\n<li>\n<p>extra abstractions introduce overhead<\/p>\n<\/li>\n<\/ul>\n<p>For high-load systems, this is critical. CUBA was not designed to replace manual optimization \u2014 it was designed to replace manual CRUD development.<\/p>\n<h4>Honest Conclusion: A Tool With a Clear Use Case<\/h4>\n<p>CUBA is not a bad tool. It is a tool with a very specific area of application, and the problems begin when people use it outside that area.<\/p>\n<p><strong>Good fit:<\/strong><\/p>\n<ul>\n<li>\n<p>MVPs and prototypes<\/p>\n<\/li>\n<li>\n<p>internal tools<\/p>\n<\/li>\n<li>\n<p>CRM and document management systems<\/p>\n<\/li>\n<li>\n<p>fast hackathon projects<\/p>\n<\/li>\n<\/ul>\n<p><strong>Poor fit:<\/strong><\/p>\n<ul>\n<li>\n<p>high-load systems<\/p>\n<\/li>\n<li>\n<p>complex custom business logic<\/p>\n<\/li>\n<li>\n<p>long-lived scalable products<\/p>\n<\/li>\n<li>\n<p>projects with migration requirements<\/p>\n<\/li>\n<\/ul>\n<h4>A Personal Observation<\/h4>\n<p>I tried many times to speed up development through Spring plugins \u2014 code generators, annotations, standardized templates. At some point I realized that CUBA is essentially an attempt to solve the same problem, but implemented as a full-fledged framework.<\/p>\n<p>And that is both its strength and its weakness:<\/p>\n<blockquote>\n<p>First, CUBA saves your time. Then it starts taking it back.<\/p>\n<\/blockquote>\n<p>If you need a fast start and a predictable result in a typical enterprise context, it is one of the best tools in Java. If you need flexibility, scale, and a long-lived product, design the architecture from scratch.<\/p>\n<p>CUBA is a power tool. Use it for its intended purpose and you will gain speed by an order of magnitude. Use it elsewhere and you will accumulate technical debt faster than you expect.<\/p>\n<p>If you have worked with CUBA or similar frameworks (Grails, JHipster, Mendix), I would be interested to hear about your experience in the comments.<\/p>\n<\/div>\n<p>\u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/1022276\/\">https:\/\/habr.com\/ru\/articles\/1022276\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>If you have ever done enterprise Java development, you have probably heard of CUBA Platform. And no \u2014 this is not about the Caribbean.CUBA is a full-stack Java framework for rapid development of business applications: CRM, document management, ERP-like systems, internal tools, and everything commonly called \u201centerprise.\u201dI worked with it in several hackathons and in a couple of real projects. And I have mixed feelings about it \u2014 that is exactly why I am writing this.What CUBA Is and Why It ExistsCUBA is built on top of Spring Framework and a number of other technologies. Its philosophy is simple:Maximize the development speed of typical business applications by removing boilerplate.Out of the box, you get:ORM via JPAa Vaadin-based UI frameworkauto-generated CRUD screensa roles and permissions systema report generatorREST APIa ready-to-use admin panelIn other words, the entire standard enterprise skeleton is already written for you. You only need to add business logic.Why It Works: A Hackathon CaseIn most hackathons I participated in, we used CUBA as a foundation. Why?Because it is incredibly fast.Here is a real-world scenario:You create an entity (for example, Order, Client, Product)You click a couple of buttons in StudioYou get a ready-made list screen, edit screen, validation, and a REST endpointAll of this happens in minutes, not days.For a hackathon, this is a killer advantage. While other teams are configuring Spring Security and writing controllers, you already have a working prototype with UI, authorization, and reports.In practice, CUBA is a very powerful admin-panel generator with the ability to attach business logic. For MVPs, internal tools, and prototypes, it is one of the fastest approaches in the Java ecosystem.Where the Problems BeginAnd this is where things get more interesting.1. Complexity Does Not Scale WellWhile the project is small, everything is great. But as soon as you get more screens, more business logic, and more non-standard cases, maintainability starts to drop.The reason is that CUBA generates a lot of XML configuration. And when there is too much XML, maintaining it becomes a separate job.2. \u201cClick-Driven Development\u201d Does Not ScaleA lot of things in CUBA are configured through Studio UI. It sounds convenient, but in practice:the same changes must be repeated manuallymodifications are spread across dozens of XML fileskeeping consistency is difficultA specific example: if you need to change one UI component across 10 forms, get ready to click through it manually 10 times. Automating this inside the CUBA ecosystem is extremely inconvenient.3. \u201cEscape to Code\u201d and the Meaning of AbstractionsAt some point, you realize that it is easier to just do it properly in code:@Injectprivate DataManager dataManager;\/\/ Custom controller, custom logic&#8230;And yes \u2014 this is possible in CUBA: there is inheritance, custom controllers, and extension of standard screens. But then the usual thing happens: you are writing a normal backend again, only on top of someone else\u2019s abstractions.And then a fair question appears: why do all these layers exist in the first place?I do not have a comfortable answer. More precisely, I do, but it is not a pleasant one: those layers were useful at the beginning, and now you are forced to live with them.4. Vendor Lock-InThis is the most serious problem. Once the project has grown:the UI is tied to Vaadin through CUBA abstractionsthe business logic is written in the paradigm of CUBA servicesconfigs, roles, reports \u2014 everything lives inside the ecosystemMigrating to something else is almost impossible. Rewriting it means starting from scratch.5. Performance Under LoadCUBA adds abstraction layers on top of JPA, and that becomes noticeable as load grows:it is hard to control the generated SQLit is difficult to optimize specific queriesextra abstractions introduce overheadFor high-load systems, this is critical. CUBA was not designed to replace manual optimization \u2014 it was designed to replace manual CRUD development.Honest Conclusion: A Tool With a Clear Use CaseCUBA is not a bad tool. It is a tool with a very specific area of application, and the problems begin when people use it outside that area.Good fit:MVPs and prototypesinternal toolsCRM and document management systemsfast hackathon projectsPoor fit:high-load systemscomplex custom business logiclong-lived scalable productsprojects with migration requirementsA Personal ObservationI tried many times to speed up development through Spring plugins \u2014 code generators, annotations, standardized templates. At some point I realized that CUBA is essentially an attempt to solve the same problem, but implemented as a full-fledged framework.And that is both its strength and its weakness:First, CUBA saves your time. Then it starts taking it back.If you need a fast start and a predictable result in a typical enterprise context, it is one of the best tools in Java. If you need flexibility, scale, and a long-lived product, design the architecture from scratch.CUBA is a power tool. Use it for its intended purpose and you will gain speed by an order of magnitude. Use it elsewhere and you will accumulate technical debt faster than you expect.If you have worked with CUBA or similar frameworks (Grails, JHipster, Mendix), I would be interested to hear about your experience in the comments.\u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 https:\/\/habr.com\/ru\/articles\/1022276\/<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-475527","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/475527","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=475527"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/475527\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=475527"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=475527"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=475527"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}