Scatter is an Inversion of Control (IoC) container for Node.js. Scatter allows you to split your project in particles (components), and then uses Dependency Injection and Service locator to link your modules together.

Applications created with Scatter are extensible out-of-the box. Since every dependency is "virtual", you can override and extend every module. In addition by using Scatter Services you can provide explicit extension points to your application.

Every module created for Scatter is totally agnostic to the IoC container and can be used even without it. Scatter modules are POJOs (Plain Old Javascript Objects), simply objects, factories and constructors that accept their dependencies as input. The only difference from a plain module is that Scatter reads an annotation named __module to extract the information to initialize the module and inject dependencies.

All the 3 components define some routes. The Scatter container allows you to write each component as if it they were all included in a single app root, as if all the sources were actually contained in a single directory (and not scattered across different components).

In this examples routes is for Scatter a namespace not a physical directory, it is a federated container of modules.

app.js

core

|-- particle.json

|-- expressApp.js

|-- routes <--- Routes

|-- home.js

`-- profiles.js

|-- data

`-- db.js

plugins

|-- privateProfiles

|-- particle.json

`-- routes <--- Routes

|-- profiles.js <--- an override

`-- private.js

|-- admin

|-- particle.json

`-- routes <--- Routes

`-- admin.js

Now if we wanted to register all the routes in our express application, the file core/expressApp.js.js would look like:

You will notice in the example above that if a new plugins is added and a new route is introduced it will not be
registered, because we reference directly the routes in the file core/expressApp. To solve this problem Scatter
supports a pattern that is a mix between DI and service locator.
The svc (Service) plugin will allow you to require a method defined in multiple modules as a dependency!

When requiring services without arguments (e.g. svc!aService) the sequence
service invocator will be returned instead of the full service object.
In practice now svc!aService === svc|sequence!aService.