Hacker News new | ask | show | jobs
by tlack 4575 days ago
If I was dealing with 40+ diverse services that I needed anywhere within various JavaScript apps, I'd probably write some kind of mediating service broker:

   var App = new YouNow();
   var Bcast = App.Api('BroadcastService');
   Bcast.Api.send(msg).then(cb);
Your code doesn't have to care about where the services come from, it just has to comply with the services' APIs.

Thinking about your code structure as backend-provided services gives you the flexibility to do a Require.JS-style async dependency loading approach if needed. Imagine the following defined in api/services/BroadcastService/index.js:

   service.define('BroadcastService', 
       ['MessagingService', 
        'VideoTranscodingService'],
       function(MS, VTS) {
          // do stuff with services,
          // return a promise
       }
   );
A style like this allows you to mix and match a bunch of different interesting architectural approaches, with relative ease, and the safety of decoupled software components.

As usual your sticking points with this kind of hierarchical component system will be caching and out-of-band (component-to-component) messaging and state changes. For instance: what happens to the notion of a global 'Session' object?