Big app design for Node.js

BIGapplication

designSaturday, November 10, 12

@sergimansilla

Saturday, November 10, 12

http://c9.io


http://c9.io

http://c9.io

Smart code completion


Static analysis


Free linux VM


Bring your own machineSaturday, November 10, 12

Real terminalSaturday, November 10, 12

Hundreds of thousands of lines of JavaScript


dynamic,weakly-typed

language


one single thread


Remote VM

Cloud9 datacenter

IDE serverRemote

VM

Remote VM

Openshift




Modularization


Black box coding



Good at abstracting away

require


Not that good at app-level abstraction

require


duplicated modules

maps to folder names

Relies on FSrequ

ire

hard to configure module


Dependency error handling

coding time compile time run time

KA-BO

OM!

- Server crash- Unhappy customers- Developer gets fired


How to fix it?

Static dependency list

Named services

Easy configuration

Resolve at startup

No FS required

Pass an object


Architect

github.com/c9/architect


https://github.com/ajaxorg/treehugger

https://github.com/ajaxorg/treehugger

Everything is a plugin

Plugins can consume plugins

An application is just a set of plugins

Architect


Dependency model

require

Architect

runtime

compile time


Dependency error handlingArchitect

coding time compile time run time

- Happy customers- Developer keeps job- Fails before release


github.com/sergi/nodejsconfit2012



Declare entity ‘cook’ with behavior

Use ‘cook’ to do some cooking


Cook Cooking action

Dependency model


package.json

Builds dependency tree

executing codewithout


{{

cook/package.json

do-‐cooking/package.json


Next

Extract the code

Wrap in Architect plugin code

Make two plugins


Function signature

Call when done


Architect plugin code

Module.exports

Options - we’ll talk about it later

Imports - everything you ‘consume’

Register - call when done




Easy to testMock dependencies


‘cook’ should be called 8 times


No black magic

Specify dependency model

Feed architect a config file

Call ‘createApp’




Configuration

Per-plugin options

No global options object

Specify in config file




Options

Passed in at startup

Options can be dependencies

Fail if options aren’t present




Your app as chunks of functionality

rather than sets of classes


chunks of functionality

Implicit type constraints

Keep implementation private

Swap features instead of interfaces


How does Cloud9 use it?

Open source version

Local version (OS + sync)

Hosted version

Normal

FTP

SSH



Swap feature per implementation

On OSS: talk local filesystem

On FTP: talk FTP library

On SSH: talk via a SSH bridge


Architect is a DI framework


But a quite special one


IDE instance(FTP)

IDE instance(SSH)

IDE instance(Normal)

IDE instance(Normal)

Single node.js process

Other code (dashboard etc.)


Architect can do

Multiple instances of same pluginRun independently

But in the same process


Centralized event bus

Loose coupling between plugins

No hard dependencies!

Can also do inter-context communication


Eventbus

Plugin

Other plugin

Emit event

React on event




And now scale

Swap it with i.e. Redis PubSub

Plugins will never notice

Modular awesomeness!


Modularize in feature blocks

Don’t over engineer

Don’t create too small blocks

They aren’t interfaces!


Avoid context switching

Less code!

Less errors!

Less boilerplate!


Loose coupling

Use (don’t abuse) an event bus

Smaller dependency graph


github.com/c9/architect


http://c9.io

http://c9.io

Happy coding!


@sergimansillagithub.com/sergi

http://c9.io


http://c9.io

http://c9.io

Technology

Big app design for Node.js