Jouke Waleson on February 12, 2013
Whether you like it or not, your software will contain bugs. Any app of reasonable size fails for certain inputs, under high load or under other sorts of unforeseen circumstances.
When this happens, you discover that a development environment is only as good as the debugging tools it offers. That’s why we want to offer the best debugging tools imaginable for our Platform as a Service. In this post I will show you how and why we created the new microflow debugger and how you should use it.
First of all, a debugger is a tool that allows you to pause a program, inspect the state and step through the execution. A remote debugger allows you to do this across a network.
The primary goals for every debugger are allowing developers to:
Like I said, we want to offer the very best debugging tools imaginable. The ultimate remote debugger would also be:
It should also be able to:
Some existing debuggers come a long way. Take a look at the Java debugger for Eclipse. It is considered to be state of the art. Nevertheless, it is not secure, (once activated anyone can connect) and it requires redeployment for activation. It is certainly not easy to set up for remote use.
We believe we have delivered something very close to the Ultimate Debugger with Mendix 4.3.0:
There is one thing that does not fit in a bullet point: The overall experience is incredibly focused on ease-of-use.
Here are some screenshots that display the debugger in action. Enabling the debugger can be done through your application management screens on the Mendix App Platform.
The debugging session is secured with a one time password.
Activating breakpoints in the Mendix Business Modeler is business as usual.
Stepping through your application’s flow. The current step is visualized with a red border.
Inspecting the state is neat too.
Because Mendix is a Platform as a Service we control the entire technology stack. Unlike most PaaS providers, we also provide the IDE and the language. This means that we can deliver a seamlessly integrated development experience.
But hey, this sounds an awful lot like marketing blah blah for a technology blog. Sorry about that. The point is: we have a lot of technological freedom to create awesome things. It also means that we can expose just the right amount of technology to you, the developer. Let us worry about servers, dns, reverse-proxies. You should worry about managing YOUR application, and we give you the tools to do precisely that.
So back to tech: All Mendix applications come with a public url where they serve HTTP responses. We decided to use that for the debugger too. It uses the same port and the same protocol as all your normal https traffic to the application. (No extra firewalls!) Once you enable the debugger with a chosen password, the Mendix Runtime registers a separate RequestHandler for the debugger: /debugger . Once started, your debugger serves at https://yourapp.mendixcloud.com/debugger/. Reusing existing HTTP infrastructure is very convenient for us and using the same url makes sense to the user.
This RequestHandler listens to incoming JSON packets like this:
It sends JSON back to the Business Modeler like this:
I bet you thought creating your own debugging interface is extremely difficult, I know I did. It turns out that simple JSON messages will suffice (for the communication channel, the rest is still quite difficult 😉 ).
Whenever a breakpoint is hit, the server needs to send (push) a message to the client. Conventional HTTP is pull only. Luckily there are ways around this. We chose to implement push with long-polling. Despite the fact that we control both the server (Mendix Runtime) and the client (Mendix Business Modeler) we reconnect every 30 seconds to avoid timeouts by intermediate servers.
When disaster strikes and you want to use the debugger in your Production environment, think twice. If you have been granted management rights to the Production environment you have been given a great responsibility. If you set a breakpoint on a commonly used microflow you will break the application for your users. Instead, you should probably be using conditional breakpoints that limit the breakpoint to a flow that will only affect you. A very useful condition is:
$currentUser/Name = '[your username]'
Can we do even better? Perhaps. The backlog for the debugger currently includes visualizing the call stack and modifying the state. With those we will get even closer to a perfect debugger.
We’d like to hear your suggestions!
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.