Question

Splitting big applications into smaller ones

2

I am currently researching how best to split a very large Mendix application in to a more maintanable set of smaller applications. I am interested to hear if anyone else has idears/best practices how best to do this. My startingpoint is to make a grand overview of the data model. From this I am able to identify logical area's for splitting the application up. For example the messaging logic has almost no connections with other data entities. Additionally I am going to seperate my user management logic so it can be shared among the smaller applications. The big challenge that I need to overcome is that in the main front-end application I want to snippets from other applications. On the dashboard I want an overview of the messages from the message app.To solve this I see three options: I could use webservices to retrieve all the relevant data, however if I do this for all seperated parts it will still lead to a very large monolithic front-end. I use webservices to retrieve a summary, and when clicking a details tab I redirect to the other app. This app wil have the same navigation structure similiar to how mendix has its sprintr and deployment app working side by side. Iframe the message app and get frustrated with resizing and resposive layouts. Any alternatives or suggestions are wecome!

asked 2017-01-16

Ralph Lenssen

4 answers

Nolan Ramsey · Answer 1 · 2017-01-16

As much as I want to answer by focusing on the "why", as splitting it doesn't always make sense, I'll stick to the question at hand assuming there is some need for the components of the app to be leveraged by other apps (such as messaging).

If the modeling was done well, you should already have logical breaks in workflows and data through the use of modules in your app. If it wasn't built with that layering in mind, you are already in a mess of trouble trying to decouple it. First you should focus on organizing the domain layers into logical function points and security needs with lots of layers.
Once that is done, splitting the app into multple apps becomes relatively easy because the hardwork was done in dividing up the data through the modules. Each module could be a self contained app if necessary, or at the very least a self contained set of processes.
If a set of workflows needs to be used by multiple apps outside of the core app, they become a good candidate for a new app built around that workflow.
Finally, build everything as REST services/webservices. App services are limited so why do that when your Java or .Net teams could leverage your workflows as well.

But circling back to the larger issue, make sure you have a compelling reason to split an app up. If organization is the issue, do it with modules first regardless. Separate apps incur license costs and overhead that might not be needed.

Ivo Sturm · Answer 2 · 2017-01-16

The approach I see mostly (and I have worked with multi app Mendix solutions a lot):

Use Mendix App Services, they are easier to maintain;
Implement a Retrieve All AppService, which retrieves all records, with only the most important attributes, to search in the grid.
When clicking on one of the rows, trigger the call to another App Service which will retrieve the full data for that specific record.

Hope this helps!

Thijs Schoemaker · Answer 3 · 2017-01-16

Hi Ralph,

Facing the same issue in other app. What the worries are:

How do you share account information? (I'am creating push services that pushes the changes from the account app to the other apps. Appservices don't create at lot of extra value, so we use just webservices.
Think about your filedocuments. When you copy the app, you have to copy your documents. But you have to remove the orphans files.
Challange: do you use push or pull to share the common data between the app's.

Ralph Lenssen · Answer 4 · 2017-02-14

Short update on our choice:
With Danny Roest from Mendix expert services we concluded that for high performing front end user experiance a solution with iframes or switching between apps wil not be enough. Therefore we are going for an architechture in which we have one single Front end application.

During the development of this application we wil make continue using the modules of Mendix to have any 'complex' logic for data enriching seperate from the viewing objects and screens. This wil make it possible for us to split this logic into a seperate application once this is needed from a performance or complexity point of view.