Big app design for Node.js

BIG
application
design
Saturday, November 10, 12

@sergimansilla


http://c9.io


Smart code completion


Static analysis


Free linux VM


Bring your own machine

Real terminal

Hundreds of thousands
of lines of JavaScript


dynamic,
weakly-typed
language

one single thread


Openshift
Cloud9 datacenter
Remote
VM

Remote
IDE server
VM

Remote
VM


Modularization


Black box coding


re
requi

Good at
abstracting away


re
requi

Not that good at
app-level abstraction


re
requi

Relies on FS
duplicated modules
maps to folder names
hard to configure module


Dependency error handling

coding time compile time run time
!
OM
- BO
KA

- Server crash
- Unhappy customers
- Developer gets fired


How to fix it?

Static dependency list Resolve at startup

Named services No FS required

Easy configuration Pass an object


Architect

github.com/c9/architect


Architect
Everything is a plugin
Plugins can consume plugins
An application is just a set of
plugins


Dependency model

require runtime

Architect compile time


Dependency error handling
Architect
coding time compile time run time

- Happy customers
- Fails before release - Developer keeps job


github.com/sergi/nodejsconfit2012


Declare entity ‘cook’ with behavior
Use ‘cook’ to do some cooking


Dependency model

Cooking
Cook
action


package.json

Builds dependency tree

without
executing code


cook/package.json

{
do-‐cooking/package.json

{

Next

Wrap in Architect plugin code
Extract the 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 test
Mock 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


Single node.js process

IDE instance IDE instance
(FTP) (SSH)
Other code
(dashboard etc.)
IDE instance IDE instance
(Normal) (Normal)


Architect can do

Multiple instances of same plugin
Run independently
But in the same process


Centralized event bus

Loose coupling between plugins
No hard dependencies!
Can also do inter-context communication


React on event
Other plugin

Event
bus

Emit event
Plugin


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


Happy coding!


http://c9.io

@sergimansilla
github.com/sergi

Big app design for Node.js

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Big app design for Node.js

Ähnlich wie Big app design for Node.js (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Big app design for Node.js