[TSTIL] mxplient

[ This is a part of "The Software That I Love", a series of posts about Software that I created or had a small part in ]

2012 - mxplient

The Mendix core had three parts:
- The MxModeler (IDE)
- The MxClient (Powering the app in the browser)
- The MxRuntime (Powering the back-end and managing the database)

I was in the Cloud team and used a Mendix app for the Cloud Portal. As we needed to automate a lot with external scripts, I needed an API in the app. Mendix had no REST functionality yet, and being Python fanatics we didn't want to touch XML WebServices.

Then I realized the app already had an API. In the browser UI, I was doing all these actions I needed to automate, and those actions went to the Runtime as HTTP requests. Using the browser debugger I discovered the undocumented API that the MxClient and MxRuntime used. I proposed just making this API public, but the Mendix core teams were very against this. Who did this junior engineer think he was? Michiel Kalkman was the main engineer of the MxClient at this time. He explained that this was a proprietary API that could change with every Mendix release. Not that that happened, but it could. Theoretically. Every couple of years. He was an extremely good senior engineer who had a lot of ideas for improvements to the API. If you're a visionary, you can get disappointed because not all of your dreams come true, or take longer than expected. In practice the API was very stable.

In the long term he was right of course, as some big releases had big changes to the protocol, but that didn't stop me. For our own use I created the "mxplient" library from the reverse engineered protocol. The P stood for Python. I used it for some small scripts, like newnode.py, or whenever I was playing around with something. One by one people started discovering the project. It was a tiny library, badly designed, and I had no idea with which Mendix versions it could work with. I think Michiel kind of appreciated the hacky way I did things. He liked Python too and had built a similar project in Ruby. I think it's the only Ruby code that was ever seen at Mendix.

Around this time we had hired Daria (QA Engineer) whose job was to test the Cloud Portal. I once showed her the script. I blinked and then one year later she had built a giant automated test framework on mxplient. Oops. Then I felt guilty and started improving it. I don't know if it's still used, but this was a nice project and became my go-to solution if I needed to automate something with Mendix.

Also around 2012, Michel Weststrate built the REST-Services module to provide a more standard and stable API to users. Years later, REST was properly added to the Mendix core itself. It's funny, Michel and I were both very productive hackers but we always had a different approach. Michel would engineer solutions as Mendix add-ons (taking quite some shortcuts). I would reverse-engineer and create workarounds completely outside of the Mendix ecosystem. Much later the "serious software engineers" picked up the pieces and made real products out of them. As Michel's work was available to the entire Mendix community, his work had a lot more traction and most got included in Mendix itself at some point.


Popular posts from this blog

AI programming tools should be added to the Joel Test

The unreasonable effectiveness of i3, or: ten years of a boring desktop environment

The long long tail of AI applications