A ‘Semi Monolith’ is a setup where your application is split into exactly two parts. Usually it does not follow the SOA paradigm but has been constructed this way for a special reason. I came in touch with it three times and gonna share my experience in this second part of my series. My gut feeling is that this setup has its place in the development universe.
A Rocket venture I worked for as CTO some years ago in Berlin was running a Java Spring application powered by a PostgreSQL database. Exotic in this case was, that most of the application logic was running in the database wired into stored procedures. The fact that every user requested ended up in exactly one Stored Procedure call made the application quite performant. The Stored Procedure itself triggered all consecutive internal calls and returned a single object back to the calling Java application. The Java business layer was quite thin and acted de facto as a caching and controller layer. This setup has been quite successfully used by Skype before us and turned out to work quite well for a while.
We were running into the following challenges:
One of Rocket’s biggest success stories, the e-commerce platform “Alice & Bob” is build around that ‘Semi-Monolithic’ architecture. A lightweight PHP frontend layer (Alice) acts as shop frontend and fetches all product and category related information from a fast key/value store. The backend layer (Bob) is build around a full-blown framework and acts as de facto business layer for the whole shop. It houses the configuration of the shop, manages the communication with the storage layer for all transaction related activities and provides a basic reporting system. We faced the following challenges:
The third and most promising of the Semi-Monolithic setups I worked with uses PHP as its frontend layer and Java/Spring as Webservice. We built an eWallet application around that stack and were quite happy with it for a while. The clear separation between view/controller- and business layer on the other side allowed us to scale the platform out selectively.
We faced the following challenges:
Me personally, I would always go with the latter setup. Java with its huge ecosystem has proven to be a very solid business option for enterprise applications. On the frontend layer however, a pure Java application behaves a bit like a behemoth and requires some basic Java skills to be mastered. From a pure feature throughput perspective I would go with some lightweight technologies like PHP, React or Angular for the frontend layer as they are relatively easy to learn and some guys really get sh!@t done with it.
Grown up in Berlin, Germany
Starting coding with 12 years on a Z80 processor
First contact with the internet in 1994 in Dublin
Living in Singapore
Lazada (Special Projects)