This time, I decided to discuss some of the experiences of debugging SmartCollections. Although this is about debugging a meteor package, I believe the same can be applied to meteor apps as well.
Normally, I don’t have access to the system(s) where the app is running since most of the issues are reported by SmartCollections users. Sometimes these issues are very hard to reproduce. Here are the tools and the procedures I use to fix those issue.
Logs are really important to find issue. With logs, I can see what is really going on. At a very early stage of SmartCollections, it didn’t have logs at all. But when the adoption of SmartCollections began to rise, people started submitting issues. At first I was clueless since there were no logs. Then I decided to add them.
First, I looked how Meteor does this internally. Unfortunately, I couldn’t find something useful. So I started to list requirements.
Using debug is very straightforward. First we need to add it to our package or app. You can use my NPM package to load
debug into your meteor app.
Then you can create a logger. Each logger has a namespace and the namespace will be used to show your logs at runtime. See below for some example.
//create logger. var debug = Npm.require('debug')('sc:coll:sample-collection'); //add a log debug('insert document: %j', doc);
While at runtime, it does not show any logs at all. We need to turn it on explicitly via an environment variable. See how I could turn on debug logs to show above.
debug supports wildcard filtering, multiple patterns and has many other useful features.
Now you can see a set of debug logs as shown below.
Sometimes, I need to figure out what are the actions applied by users exactly. In my case, I also needed to know what is exactly flowing over the wire and which order they are flowing.
Solution is to log DDP messages. We’ve a very good tool for that and I’ve introduced it a few weeks back. See DDP Analyzer.
Once I got the Debug logs and DDP logs, it is very easy to isolate the issue. After the isolation, I will try to reproduce it locally.
Once reproduced, we can use
node-inspector to see what is really happening inside.
node-inspector has been re-touched recently and now it is much stable and feature rich.
I hope these tools and the process will help you to debug your app or package. If I have missed something or you have a better way to do any of this, let us know about it.
Thank You, Aloka Gunasekara for editing the article.