Question

Mendix Architecture Design - Using Non-Persistent Entities Only

0

Hey everyone! I wanted to ask a core design question when it comes to using Mendix and understanding both it’s advantages and disadvantages. My use-case, I’m going to have many employees all performing the same job functions within this app, and I want the data that they access to just be living during their session only. My hope was that I would be storing no persistent tables on the Mendix platform. All data access will be done exclusively via APIs that we’ve developed, and then the data would be stored in non-persistent entities for the user to access in memory during their session. This way, we only have to ensure data integrity in one spot where our application database lives and I dont have to worry about syncing between our existing databases our companies use, and mendix’s databases. Are there any major disadvantages with this design when it comes to developing that I should be aware of? After playing a little with non-persistent entities, it seems to be behaving drastically different than persistent entities, especially as you start pointing datasources to them and trying to select attributes from non-persistent entities. Nothing with non-persistent entities seems to be showing up in the GUI when selecting drop downs, and I fear the route of going “non-persistent” is just going to be more painful for developing if i have to then do absolutely everything with Microflows as data sources instead of just simple select from the GUI. Has anyone else gone with this design approach of going full non-persistent? Biggest advantages, biggest disadvantages you’ve seen when developing?

asked 2020-04-28

Matthew Nguyen

4 answers

Gregor Brett · Answer 1 · 2020-04-29

I am new to Mendix and have a similar issue. I am reading all my data from an SAP system via REST calls and so it would seem wrong to store it in a persistent entity. I want a single source of truth and I don’t want to have to clean up persistent entities at the start/end of a process.

I find Mendix state management confusing and I am never sure what is in scope at any one time but my suggestion would be to try to pass in the top level entity into your pages if you can and drill down from there via associations in your screen via data views/list views. That seems to work best for me but I am a beginner too so YMMV!

Joost Stapersma · Answer 2 · 2020-04-29

Advantages:
-Less/no need to synchronize master data between databases (as you already indicated)
-Security: even if someone were to obtain a database snapshot, it would contain a lot less sensitive data :)

Disadvantages:
-If the API is down, your entire application will be useless as it will depend on the API's for showing data.
-Working with only non-persistent objects causes challenges that might hurt overall development speed. For example, maintaining the (size of the) client state and the inability to use Xpath constraints and/or entity access to filter data.

I am sure there are more, but these are the ones that came to mind first!

Tim v Steenbergen · Answer 3 · 2020-04-28

Just some thoughts on this:

Be careful with functions that delete objects, since that may still lead to unwanted behavior if someone else in the meantime saved changes using that object.

Not storing your data makes data-integrity more likely, but it is no guarantee. The longer the session takes, the bigger the chance of data-integrity getting violated.

Some nice reading: an old blog post from the time non-persistent entities got introduced in Mendix: https://www.mendix.com/blog/persistence-is-futile.

Build this in Mendix’ latest release Native app. That has some neat tricks that will certainly help you. Even calling services from frontend instead of from the server.

Michiel Arts · Answer 4 · 2020-04-30

I've seens several systems trying to go completely non-persistent. Some with more success than others.

One major issue these apps have been struggling with is that every search/sort/pagination function can not be done using xpath or database queries. This lead to not using many of the default search/sort/pagination features of datagrids, a lot of custom code and looping through lists in microflows. This often leads to an explosion of complexity.

In one of the apps i have refactored the non-persistent entities to persistent entities for many of those entities. I then used entity access based on owner to hide the data of different users from each other. I'm still not sure if that was the best approach, but it reduced complexity a lot.