aws-sdk module should be optionnal in package.json

[mycaule]

Since it's a 15Mb dependency, the user should explicitly do require('aws-sdk') in my opinion.

[arvindr21]

@mycaule Since this is a node module, we would not want a user to manually installing dependencies. If you do not need the dependency.you can always fork this repo and modify accordingly :).

Let me know what you think.

[mycaule]

In the passport authentification module, users can choose how to login with a strategy. For example, if I want to login with twitter account, I would install passport and passport-twitter strategy, but if I want to login with facebook account, I would install the passport-facebook strategy.

If your goal it to provide a lightweight module, I think this plugin point of view is an interesting approach to let users explicitly install AWS packages if they want to use Amazon, other packages if they want Azure, Google App Engine or whatever...

The same remark applies to thumbnails creation techniques (imagemagick, cairo...).

I was just checking the space used by my Node.js project, and this aws package took about 30% the size of it which seems a lot in production. Some companies don't want to give their data to Amazon or Google, so it might also seem strange to have to install that aws package.

[arvindr21]

Nice idea @mycaule I am planning to refactor the project. I will try and push this along with it. Thanks for the suggestion.

[mycaule]

jasmine-node should be a in the devDependencies section as well. This is how async or express handles unit tests runner as a comparision.

[mycaule]

Another famous package with plugin features is winston. What they call transports is similar to passport's strategies. Basically what winston does is provide a way to write logs in different formats.

winston's source code might be easier to study since it's basic input output stuff whereas passport is about authentication and cryptography. They are likely to use the same design pattern though.

[arvindr21]

Interesting design. Thanks for sharing.

[arvindr21]

@mycaule Do you have any design in mind how we can refactor the existing code?

[mycaule]

I'm gonna have a look at the problem on this winter break. I have read some interesting things about inversion of control and dependency injection, I think it will be a good challenge to apply it there. :)

[arvindr21]

Sure. Can you share any articles on that?

[mycaule]

Actually, I am currently learning the AngularJS frontend framework.

One interesting aspect of AngularJS is how they use Dependency Injection (DI) as a plugin system. They talk about it in the very beginning of their documentation. They claim it's the main reason why their framework can be unit tested (with jasmine) and end-to-end tested (with protractor) in a comprehensive manner as everything can be mocked up.

DI is just a general software pattern to safely add functionality to an app and testing it.

It kind of rang a bell when I also remembered that Michael Feathers talked about it his book Working effectively with legacy code. That book is considered a reference in dealing with legacy code and applying TDD techniques.

Regarding our problem about adding a plugin system to the package, there seems to be one NPM package maintained by Nodejitsu called broadway, there a small tutorial in the links below, I think we can use it easily if that package dependency is acceptable.

I am still going to check how winston did implement this anyway, just by curiosity.

Further reading :

• https://code.angularjs.org/1.2.28/docs/guide/di
• http://stackoverflow.com/questions/130794/what-is-dependency-injection
• http://googletesting.blogspot.fr/2008/07/how-to-think-about-new-operator-with.html
• http://blog.nodejitsu.com/ioc-and-dependency-injection-with-broadway/

[arvindr21]

Very interesting.. Thanks for sharing!!

[mycaule]

This guy did a benchmark of NPM packages for dependency injection. http://www.mariocasciaro.me/dependency-injection-in-node-js-and-other-architectural-patterns