

The open-source node libraries powering Cloud9 - mattpardee
http://c9.io/site/blog/2012/07/the-open-source-node-libraries-powering-cloud9/

======
tlack
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?

~~~
creationix
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.

~~~
tlack
(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

~~~
creationix
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.

