Ever tried configuring your development machine for debugging code executing on a remote server? Most likely you know then just how difficult things can get: configuring the IDE, finding out the right remote port, making sure it’s all routed through the firewall, selecting the right protocol, ensuring debugger front and backend software versions are compatible…
The backend software driving the development tool chain of the mCAP platform is realized as an ordinary MEAP application, no difference to the applications written by you! It comes preinstalled and may serve as engineering example for this overview, the mCAP Studio backend. Let’s go through the code by debugging: log on to the server, then direct your browser to
and it’ll take you right into the debugger showing the code:
In short, debugging server-side code works just like on the client-side. Pressing the pause button at the top right doesn’t do much yet, as the script is idle listening for requests to handle. In this state not much resources are consumed, since unlike most other node.js emulation environments the mCAP runtime does not reserve a dedicated thread driving the event loop, but allocates one when necessary only. So after the pause was requested, opening
for example (in another browser tab) will cause the debugger to break into code.
The studio backend is an express.js app and as such it ends with
app.listen(). The listen establishes a virtual web server (ignoring any port number passed) and takes care of the routing and URL rewriting necessary for integrating the script into the server environment. For convenience, the studio backend provides a default entry point listing all available REST calls supported by itself. Search for
close to the top, set a break point and request
to break into the
On break the call stack is exposed on the right, variables in scope can be inspected easily. By clicking the icon on the lower left the interactive console is attached to the view. It operates on the current stack frame (if any), also allows easy inspection and provides even auto completion. Using the console it is easy to check the authorization of the current remote user, first line of screenshot:
When passing objects to the
console.log(...) function conversion to JSON is done automatically. Also, this output appears in the server logfiles and can be printed at different levels of detail using
console.trace...error(...) functions. While debugging security issues you may find it valuable to add
as a watch expression.
The screenshot was taken while being suspended in a break point, making the event loop halt for the moment. As a consequence, the immediate callback installed in the last line is not executed until execution is resumed:
An important detail is how the system maintains the authorization state here. The output of the immediate callback is same as beforehand, i.e. the remote user, an ADMIN in my case. When querying the state some later point, the anonymous authorization is reported. This is because execution was resumed, so that the console now operates at the global level and thus outside of an asynchronous control flow originating from a request. At this global level no impersonation takes place. Notice, in general script initialization takes place with anonymous authorization.
Want to learn more about writing applications using a mobility platform? Get started with a free trial tutorial and build your applications and enhance your developing experience with mCAP® Brackets or mCAP® CLI.