Multiple ng-apps : booster rockets for re-usable design

ng multiple apps with booster
ng multiple apps with booster

When i started learning angular , I just happened to take ng-app directive for granted. And innocently so, thought since Angular has been marketed as a ‘Super heroic JS framework’ that works best with Single page applications, it must be using not more than one ng-app. Why else would it need 2 apps and what could it possibly do with it ?

All the students get along believing a single ng-app would suffice for the entire project. When it gets real dirty with the directives it is too much to expect the students to think of design patterns.

At the end of it having to see the miraculous app work with absolutely ZERO impedance mismatch is a wonderful feeling. But then when it comes down to thinking if you can really use this as a piece all over again without having to re-write it, is the point where you can start appreciating this post better.

I’m not doubting your abilities to finding patterns , believe me, no presumptions of your cognizance that there could be patterns here. I’m perhaps just too excited to stumble on this particular personal accidental workplace discovery.

Angular is just too awesome not to leave out room for extension. The very idea of having to teach HTML some new tricks and make it come alive is so extraordinary that things to follow are bound to hold us in awe!

One starts to think , directives , yes! Directives of course are plug and play.(With small tweaking though, need to remove all the app bindings) But what happens to providers ?  controllers ? – perhaps not !!  It is not so easy to make them re-usable. Can you really pluck out your controllers from one project and just place them with a new application ? – Sounds crazy , but then not really. 

We need apps to be designed independently , perhaps based on functionality but we need something as a lowest indivisible unit of the webapp that can carried ahead as a re-usable unit

Coming to think of it , ng-app seems to be the best , after all all the controllers, directives, routes are all bound to the module.

But then unfortunately this is not possible. Angular does not allow you to cascade apps as done below.



Angular apps (modules) cannot be cascaded ! – angular just refuses to have an app underneath another one. Logically so yes that would make sense. Else we are just giving way to much of deluge of scopes.

What then can be brilliantly done is :

app referencing is rather a smarter way
app referencing is rather a smarter way

And now that you have one app referencing the other, apps like this can be re-usable and plug and play. Go ahead divide your functionality into smaller pieces and enjoy the goodness of Angular!!


Mongo C# driver 2.0 is not as evil as it sounds

What got me too , and perhaps must have got you as well was that the C# driver 2.0 for Mongo was actually a bit of odd ball! There is so much decry over the fact that the driver allows only async methods is that you start believing it could really be evil afterall!

A bunch of developers are complaining that “async-only” APIs would mean you have performance hit rather than gain since the number of threads is actually not even considerable. Yeah agreed! – thread cleaning and management in cases of lesser loads means it is rather slower. But ask a guy like me who has used ORM (Object relational mapping) and LINQ over SQL server, Mongo C# (despite async-only) is a pleasure !

People who have not worked with asynchronous programming are most likely to to find this a bit odd , but that ‘s as far it can go. Slightly sour for the regular taste buds , until once you gulp it down you would actually start enjoying.

public async Task<IEnumerable<OfType>> function(){

var task = MongoClient.GetCollection(“name of the collection”).Find(filter).ToListAsync( );

//happy to do all the independent stuff here , while the database would get me results.

await task;

return task.Result; //this result is expected to be an enumerable


was that any twisted ? Not at all !!

Rather the fact that this has done away with Entity Framework  / ADO.NET pain is like a delight. The async statement is not even a concern for me. Yeah perhaps a bit un-natural but not as tedious as this in EF ..

This is how I would get things from SQL EF over LINQ

public  IEnumerable<ofType> GetFunction(){

using(dataContext  db = new dataContext){

db.Entities.Where(Predicate filter).Select(x=>x).toArray( );



the innocent looking SQL LINQ code above has a draconian EF ORM model behind the scenes.

  • Objects from the ORM are not directly serializable in case you are using database first scaffolding. So then Serializable business models and ORM models then need to be fungible. Alas! -sheer agony of writing object conversion code.
  • code-first scaffolding obviously needs a lot of effort, not that Mongo does not have POCO business models, but the pain of synchronizing the model with the tables and the relations is serious.

Mongo – no tables, no relations, no PK-FK, and hence no FK violations. That to me is such a relief ! Who cares if it is async APIs or Sync APIs ..

Create a free website or blog at

Up ↑