Hi Jason,

I can share my understanding on this, but this is really tough to answer since it involves understanding backend design, which Mendix hasn’t exposed fully :)

Ques – when a PE object is retrieved I assume it now lives in memory, would there be a reason to close a PE to NPE for security or performance reasons?
Ans – The basic reason for choosing PE or NPE, is whether you need an object even after the session ends. Now thinking from performance aspects, it should be faster since retrieval for NPE objects always happens from runtime instead of the server, and talking about security, entity access rules aren’t applicable for NPE and other security rules will be exactly behave same, so I don’t see much of an advantage.

Ques – and how does this work with NF vs MF?
Ans – if we talk about retrieve activity, then whatever object it is, the query will get converted into OQL at the runtime level and then further into SQL at the server level. So ideally should work the same in both places except the query might differ (security related) because of the different abilities of PE and NPE.

Ques – is Mendix smart enough to know when to do manipulation locally or serverside, or is this something I can control, and should think about?
Ans – I think it all depends on caching, think this like how CPU handles memory management using paging or segmentation, the same way a program might have been placed at the Mx runtime to handle such scenarios and I believe we can’t control it (I can be wrong also).

Ques – Also how can an NF retrieve from the database or commit if it runs clientside? or do you commit to memory/refreshing?
Ans- I think internally it can call microflows, so maybe internally it creates commands which are similar to mf call and get it executed.

Not sure, how much these answers will help but it was fun thinking about how it works.

Regards,
Naman