Refactor loopback-explorer integration in app.js template

[bajtos]

See the discussion in #33. We are trying to move app.start from loopback-explorer to loopback. The current integration with loopback-explorer is causing troubles:

• workspace's app.js is loading the module
• loopback's app.start wants to report the explorer's URL

Proposed solution:

1. The code loading plugins (i.e. loopback-explorer) is responsible for handling the case where the module is not available.
2. The plugin (loopback-explorer) is responsible for reporting information useful to the user. The message should be printed from an even handler listening on a new "start" event that is emitted by the app.start().

[bajtos]

The approach described in the issue is problematic.

1. LoopBack does not provide logging facilities. The plugin does not know how to report useful information (help messages). Should it use console.log? Or console.error? Or winston module? Perhaps bunyan?

2. Depending on the configuration and environment, LB users might not want to print help messages. For example, there is little use for help messages when running in production.

3. LoopBack is trying to be not opinionated, settling down on a single logging facility is IMO against that vision.

4. We can't rely on app.listen()/app.start() being called. Since LB app is an express app, it can be mounted on another app instead of installing it as top-level HTTP handler. In this case the help messages will get completely lost.

   var lb = loopback();
   lb.boot();
   
   var app = express();
   app.use('/v1', lb);
   app.listen(3000);

My conclusion is that help messages should stay in the code generated by templates.

How the templated solution could look like:

/** app.js **/

app.boot();

app.start = function() {
  app.listen(function() {
    var baseUrl = 'http://' + app.get('host') + ':' + app.get('port');
    app.emit('start', baseUrl);
    console.log('LoopBack server listening @ %s', baseUrl);
  });
};

if(require.main === module) {
  app.start();
}

/** middleware/explorer.js **/
var app = require('../app.js');
try {
  var explorer = require('loopback-explorer')(app);

  // this is a mock-up, the real API should look better
  app.configureMiddleware({
    stage: '3-request-handlers', 
    route: '/explorer',
    handler: explorer
  });

  app.on('start', function(baseUrl) {
    console.log('Browse your REST API at %s%s', baseUrl, explorer.route);
  });
} catch (e) {
  console.log('Run `npm install loopback-explorer` etc.');
}

The mechanism of app.start and app.on("start") stays inside the generated code. What's important, it is providing only "start" event, everything else is handled by loopback core.

This way it's easy for LB users to compose the components in a different way.

---

Since the middleware registration was not extracted into LoopBack core yet, the patch for this issue will inline the content of middleware/explorer.js inside the main app.js.

[bajtos]

Closed by #63.