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.
What should you expect?
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:
- Figure out what the bleep is going wrong as fast as possible
- Inspect the state
- Trace and control the application flow
Like I said, we want to offer the very best debugging tools imaginable. The ultimate remote debugger would also be:
- easy to use
- easy to set up
It should also be able to:
- activate on all environments (some errors only appear to happen in production 😉 )
- activate/deactivate without restarting the application
- visualize the execution flow
- specify conditions for breakpoints
- modify variables in the current frame
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:
- It is fast. There is no noteworthy overhead to enabling the debugger, and the debugger responds to commands right away.
- It is secure and very easy to set up. The Mendix App Platform creates a one time password each time you click the enable debugging button. Paste that password in the Business Modeler and you’re connected.
- It does not require restarting the environment. You can enable debugging NOW.
- It can be activated on Production, if you think that that is necessary. Setting a breakpoint that is triggered by all of your users will stop them dead in their tracks, so caution is advised.
- You can visually step through your flow! The debugging client is the Mendix Business Modeler with your project opened. Your Microflow actions will light up nicely when the debugger steps through them! Perhaps you thought that visual modeling is just a fancy gimmick, but here it shows its true colors.
There is one thing that does not fit in a bullet point: The overall experience is incredibly focused on ease-of-use.
Show me the money!
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.
Under the hood
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!