The open-source node libraries powering Cloud9(c9.io)
c9.io
The open-source node libraries powering Cloud9
http://c9.io/site/blog/2012/07/the-open-source-node-libraries-powering-cloud9/
1 comments
Architect is an interesting concept. I had thought about doing something similar using EventEmitter as a kind of "plugin bus" between different parts of the app. Has anyone who has used something like this for complex sites comment on implementation strategies and how they grow with age?
The neat thing about architect is that some plugins provide "services" or named APIs and other plugins consume such named APIs. It's interface oriented programming. The service names are simple short strings and that's why architect has a feature to alias services should name conflicts arise.
Using pure events works too (as does dnode and smith), but for large projects they tend to get hairy. Architect separates concerns into defined interfaces provided by configurable plugin instances. It keeps things clean and configurable.
Using pure events works too (as does dnode and smith), but for large projects they tend to get hairy. Architect separates concerns into defined interfaces provided by configurable plugin instances. It keeps things clean and configurable.
(This question is a bit difficult for me to phrase, so pardon me if this sentence is awkward) Can you give me an example of how this plugin architecture saved you from an awkward happenstance? For instance, what did this level of abstraction actually buy you in specific? What did you vary (for lack of a better term) that the consumer didn't have to worry about, as opposed to if you had built it in a traditional tightly coupled manner?
I am trying to understand how this abstraction comes into play in day to day work as apps are put together.
Thanks again for your insightful reply
I am trying to understand how this abstraction comes into play in day to day work as apps are put together.
Thanks again for your insightful reply
Cloud9 is a very large application. We have many developers working around the clock in different time zones constantly.
The main thing that helps us work together is clearly defining the interfaces between different modules or pieces of the system and keeping things encapsulated.
For example, I work on the VFS interface that other parts of the system use to access workspaces. If I follow semver, then I can push bugfixes without breaking other's code. If I have to change my interface, then I bump the minor version.
Granted, normal npm modules already provide a lot of this. They have semantic versions and the module name is the name to the API interface. We use vanilla npm modules as well. Architect is a layer on top of this.
The real strength of architect over just plain npm dependencies is the config file. You build your architect application as a JSON (or JS) config file that tells the system what plugins to load and what parameters to provide to each. Since the plugins are decoupled and never touch eachother except through defined architect services, it's easy to see if a dependency is missing. You can replace a dependency with some other module that implements the same interface. This makes manual and automated testing much easier. If I want to test my new feature in isolation, I configure a minimal version of the app and add in my plugin. Then I can add more and more plugins as I test to make sure it integrates with everything. I can switch between config profiles with a single flag.
Also having opposing timezones makes it impossible to make real progress on tightly coupled systems. San Francisco is drinking morning coffee when Amsterdam is going home, I'm in between in Red Lick, Texas.
Architect is just a tool that helps in some cases. The important rule is to decouple modules using some tool (vanilla npm, architect, or something else) and then take interfaces seriously. This makes testing sane, distributed development efficient, and large programs possible.
The main thing that helps us work together is clearly defining the interfaces between different modules or pieces of the system and keeping things encapsulated.
For example, I work on the VFS interface that other parts of the system use to access workspaces. If I follow semver, then I can push bugfixes without breaking other's code. If I have to change my interface, then I bump the minor version.
Granted, normal npm modules already provide a lot of this. They have semantic versions and the module name is the name to the API interface. We use vanilla npm modules as well. Architect is a layer on top of this.
The real strength of architect over just plain npm dependencies is the config file. You build your architect application as a JSON (or JS) config file that tells the system what plugins to load and what parameters to provide to each. Since the plugins are decoupled and never touch eachother except through defined architect services, it's easy to see if a dependency is missing. You can replace a dependency with some other module that implements the same interface. This makes manual and automated testing much easier. If I want to test my new feature in isolation, I configure a minimal version of the app and add in my plugin. Then I can add more and more plugins as I test to make sure it integrates with everything. I can switch between config profiles with a single flag.
Also having opposing timezones makes it impossible to make real progress on tightly coupled systems. San Francisco is drinking morning coffee when Amsterdam is going home, I'm in between in Red Lick, Texas.
Architect is just a tool that helps in some cases. The important rule is to decouple modules using some tool (vanilla npm, architect, or something else) and then take interfaces seriously. This makes testing sane, distributed development efficient, and large programs possible.