The first variation of the plugin we are now going to implement covers the case in which our application mainly uses hardcoded dependencies for wiring its stateful modules. In this context, if our plugin lives in a package under the node_modules directory, to use the services of the main application we have to gain access to the parent package. We can do this in two ways:

The first technique is less robust as it assumes that the package is aware of the position of the main application. The module impersonation pattern can instead be used regardless of where the package is required from, and for this reason, this is the technique that we are going to use to implement the next demo.

To build our plugin, we first need to create a new package under the node_modules directory, named authsrv-plugin-logout. Before we start coding, we need to create a minimal package.json to describe the package, filling in only the essential parameters (the complete path to the file is : node_modules/authsrv-plugin-logout/package.json):

{ 
  "name": "authsrv-plugin-logout", 
  "version": "0.0.0" 
} 

Now we are ready to create the main module of our plugin, we will use the file index.js, as it is the default module that Node.js will try to load when requiring the package (if no main property is defined in the package.json). As always, the initial lines of the module are dedicated to loading the dependencies; pay attention to how we are going to require them (file node_modules/authsrv-plugin-logout/index.js):

const parentRequire = module.parent.require; 
 
const authService = parentRequire('./lib/authService'); 
const db = parentRequire('./lib/db'); 
const app = parentRequire('./app'); 
 
const tokensDb = db.sublevel('tokens'); 

The first line of code is what makes the difference. We obtain a reference to the require() function of the parent module, which is the one that loads the plugin. In our case, the parent is going to be the app module in the main application, and this means that every time we use parentRequire(), we are loading a module as if we were doing it from app.js.

The next step is creating a proxy for the authService.login() method. After studying this pattern in Chapter 6, Design Patterns, we should already know how it works:

const oldLogin = authService.login;                    //[1] 
authService.login = (username, password, callback) => { 
  oldLogin(username, password, (err, token) => {       //[2] 
    if(err) return callback(err);                      //[3] 
 
    tokensDb.put(token, {username: username}, () => { 
      callback(null, token); 
    }); 
  }); 
} 

In the preceding code, the steps performed are explained as follows:

Similarly, we need to intercept the calls to checkToken() so that we can add our custom logic:

const oldCheckToken = authService.checkToken; 
 
authService.checkToken = (token, callback) => { 
  tokensDb.get(token, function(err, res) { 
    if(err) return callback(err); 
 
    oldCheckToken(token, callback); 
  }); 
} 

This time, we first want to check whether the token exists in the database before giving control to the original checkToken() method. If the token is not found, the get() operation returns an error; this means that our token was invalidated and so we immediately return the error back to the callback.

To finalize the extension of the authService, we now need to decorate it with a new method, which we will use to invalidate a token:

authService.logout = (token, callback) => { 
  tokensDb.del(token, callback); 
} 

The logout() method is very simple: we just delete the token from the database.

Finally, we can attach a new route to the Express server to expose the new functionality through a web service:

app.get('/logout', (req, res, next) => { 
  authService.logout(req.query.token, function() { 
    res.status(200).send({ok: true}); 
  }); 
}); 

Now our plugin is ready to be attached to the main application. To do this we just need to go back to the main directory of the application and edit the app.js module:

// ... 
let app = module.exports = express(); 
app.use(bodyParser.json()); 
 
require('authsrv-plugin-logout'); 
 
app.post('/login', authController.login); 
app.all('/checkToken', authController.checkToken); 
// ... 

As we can see, to attach the plugin we only need to require it. As soon as this happens—during the startup of the application—the flow of control is given to the plugin, which in turn will extend the authService and the app modules, as we saw earlier.

Now our authentication server also supports the invalidation of the token. We did that in a reusable way, the core of the application remained almost untouched, and we were able to easily apply the Proxy and Decorator patterns to extend its functionalities.

We can now try to start the application again:

node app

Then, we can verify that the new /logout web service actually exists and works as expected. Using curl, we can now try to obtain a new token using /login:

curl -X POST -d '{"username": "alice", "password":"secret"}' http://localhost:3000/login -H "Content-Type: application/json"

Then, we can check whether the token is valid using /checkToken:

curl -X GET -H "Accept: application/json" http://localhost:3000/checkToken?token=<TOKEN HERE>

Then, we can pass the token to the /logout endpoint to invalidate it; with curl, this can be done with a command such as this:

curl -X GET -H "Accept: application/json" http://localhost:3000/logout?token=<TOKEN HERE>

Now, if we try to check the validity of the token again, we should get a negative response, confirming that our plugin is working perfectly.

Even with a small plugin like the one we just implemented, the advantages of supporting plugin-based extensibility are clear. We also learned how to gain access to the services of the main application from another package using the module impersonation.

Module impersonation is, of course, a form of hardcoded dependency and shares with it strengths and weaknesses. From one side, it allows us to access any service of the main application with little effort and minimal infrastructural requirements, but from the other, it creates a tight coupling, not only with a particular instance of a service but also with its location, which more easily exposes the plugin to changes and refactoring in the main application.

Similar to module impersonation, the service locator is also a good choice if we want to expose all the components of an application to its plugins, but on top of that, it has a major advantage, because a plugin can use the service locator to expose its own services to the application or even to other plugins.

Let's now refactor our logout plugin again to use a service locator. We'll refactor the main module of the plugin in the node_modules/authsrv-plugin-logout/index.js file:

module.exports = (serviceLocator) => { 
  const authService = serviceLocator.get('authService'); 
  const db = serviceLocator.get('db'); 
  const app = serviceLocator.get('app'); 
 
  const tokensDb = db.sublevel('tokens'); 
 
  const oldLogin = authService.login; 
  authService.login = (username, password, callback) => { 
    //...same as in the previous version 
  } 
 
  const oldCheckToken = authService.checkToken; 
  authService.checkToken = (token, callback) => { 
    //...same as in the previous version 
  } 
 
  authService.logout = (token, callback) => { 
    //...same as in the previous version 
  } 
 
  app.get('/logout', (req, res, next) => { 
    //...same as in the previous version 
  }); 
}; 

Now that our plugin receives the service locator of the parent application as the input, it can access any of its services as needed. This means that the application does not have to know in advance what the plugin is going to need in terms of dependencies; this is surely a major advantage when implementing a plugin-controlled extension.

The next step is to execute the plugin from the main application, and to do that, we have to modify the app.js module. We will use the version of the authentication server already based on the service locator pattern. The required changes are given in the following block of code:

// ... 
const svcLoc = require('./lib/serviceLocator')(); 
svcLoc.register(...); 
// ... 
 
svcLoc.register('app', app); 
const plugin = require('authsrv-plugin-logout'); 
plugin(svcLoc); 
 
// ... 

The changes are highlighted in the preceding code; those changes enabled us to:

As we already said, the main strength of the service locator is that it provides a simple way to expose all the services of an application to its plugins, but it can also be used as a mechanism for sharing services from the plugin back into the parent application or even other plugins. This last consideration is probably the main strength of the service locator pattern in the context of plugin-based extensibility.

Using DI to propagate services to a plugin is as easy as using it in the application itself. This pattern becomes almost a requirement if it's already the main method for wiring dependencies in the parent application, but nothing prevents us from using it when the prevalent form of dependency management is hardcoded dependencies or a service locator. DI is also an ideal choice when we want to support an application-controlled extension because it provides better control over what is shared with the plugin.

To test these assumptions, let's immediately try to refactor the logout plugin to use DI. The changes required are minimal, so let's start from the main module of the plugin (node_modules/authsrv-plugin-logout/index.js):

module.exports = (app, authService, db) => { 
  const tokensDb = db.sublevel('tokens'); 
 
  const oldLogin = authService.login; 
  authService.login = (username, password, callback) => { 
    //...same as in the previous version 
  } 
 
  let oldCheckToken = authService.checkToken; 
  authService.checkToken = (token, callback) => { 
    //...same as in the previous version 
  } 
 
  authService.logout = (token, callback) => { 
    //...same as in the previous version 
  } 
 
  app.get('/logout', (req, res, next) => { 
    //...same as in the previous version 
  }); 
}; 

All we did is wrap the plugin's code into a factory that receives the services of the parent application as the input; the rest of it remains unchanged.

To complete our refactoring, we also need to change the way we attach the plugin from the parent application; let's then change that one line where we require the plugin in the app.js module:

// ... 
const plugin = require('authsrv-plugin-logout'); 
plugin(app, authService, authController, db); 
// ... 

We intentionally didn't show how these dependencies were obtained. In fact, it doesn't really make any difference, any method will equally work; we might use hardcoded dependencies or obtain the instances from factories or from a service locator—it doesn't really matter. This proves that DI is a flexible pattern when wiring plugins that can be used regardless of the way we wire the services in the parent application.

But the differences are much more profound. DI is definitely the cleanest way of providing a set of services to a plugin, but most importantly, it offers the best level of control over what's exposed to it, resulting in better information hiding and better protection against overly aggressive extensions. However, this can be also considered a drawback, because the main application can't always know what services the plugin is going to need, so we end up either injecting every service, which is impractical, or only a subset of them, for example, only the essential core services of the parent application. For this reason, DI is not the ideal choice if we mainly want to support plugin-controlled extensibility; however, the use of a DI container can easily solve these issues.

module.exports = function(grunt) {
  grunt.registerMultiTask('taskName', 'description',
    function(...) {...} 
  ); 
};

Taking the previous example as a starting point, we can use a DI container in combination with our plugin by applying a small change to the app module, as shown in the following code:

// ... 
const diContainer = require('./lib/diContainer')(); 
diContainer.register(...); 
// ... 
//initialize the plugin 
diContainer.inject(require('authsrv-plugin-logout')); 
// ... 

After registering the factories or the instances of our application, all we have to do is instantiate the plugin, which is done by injecting its dependencies using the DI container. This way, each plugin can require its own set of dependencies without the parent application needing to know. All the wiring is again carried out automatically by the DI container.

Using a DI container also means that each plugin can potentially access any service of the application, reducing the information hiding and the control over what can be used or extended. A possible solution to this problem is to create a separate DI container registering only the services that we want to expose to plugins; this way, we can control what each plugin can see of the main application. This demonstrates that a DI container can also be a very good choice in terms of encapsulation and information hiding.

This concludes our last refactoring of the logout plugin and the authentication server.