0

Today I watched a youtube video https://www.youtube.com/watch?v=vXjVFPosQHw on Scalable Javascript Application Architecture and I really like how simply author have explained the concept of architecture.

After watching that video I am thinking of making small-2 changes in my javascript code to improve quality of software.

I am using Angular 1 in my application. Since watching that video I am trying to fit angular in that stack..

Below is my understanding for the same.

Unlike other libraries like jQuery, YUI or DOJO, keeping angular in Base Libraries category won't be correct, as Angular is not just a bunch of utility functions to make ones life easy. It is much more than that, it is a complete MV* solution with many other utility functions like $http, $timeout services...

Second place where I though one can keep Angular is Module. We can create different-2 modules in angular and then write our own code to implement Sandbox and Application Core. And make Module code make use of Sandbox. But keeping Angular here is again not correct as Modules will tightly depend on third party tool (Angular in this case), which should be avoided as per the video.

Third place: (http://serebrov.github.io/html/2013-03-18-js-scalable-architecture.html)

base library - jQuery or angular's own jqLite implementation

app core - angular itself

sandbox - scope passed to the controller

module - angular's controller

But I am not convinced with the above definition. fact that module is angular's controller, scope is sandbox are not really convincing to me.

I am unable to find a place for angular in that stack, because the moment you start using Angular in your code you really start thinking in terms of MVC, not in terms of sandbox, base library, application core. Also if you are using angular in your code, then you are pretty much saying that I am not gonna replace Angular with some other MVC framework.

Question 1: Does Angular fit in that stack?

Question 2: If Yes, then where?

csjoshi04
  • 51
  • 7
  • In order to swap an implementation you need an abstraction and creating such an abstraction for an entire framework is quite impractical IMO. The idea to be able to switch from one MV* framework to another by just writing a new concrete implementation of an abstraction is quite utopic, but not pragmatic. You'd better pick the right MV* framework and benefit from all the features it has to offer. – plalx Jun 16 '16 at 04:37
  • However, this is not the point of the scalable architecture. The main aspect of this architecture would be that modules are decoupled from each other and have loosely coupled dependencies. If you follow angular best practices your code will have those characteristics. Another aspect of the architecture is that modules are based on an abstraction allowing a core to handle them in a generic way. This enables a plugin-based architecture where each module can self-register while having their life-cycle maintained by a core. – plalx Jun 16 '16 at 04:40
  • Angular doesn't offer a native solution to that, but doesn't prevent you from implementing one. For instance, in one of my application, modules were self-registering and would register their own routes and menu items through a core. – plalx Jun 16 '16 at 04:47
  • Plalx, to your second point, agreed, the point of scalable architecture is to have loosely coupled application modules. But if you really think about your angular app you need to have dependencies in modules. One module depends on another module. If you watch the video, he clearly says modules should not know about each others existance. Assuming you are referring to angular.module(), not theoretical module. How will you achieve this in angular? – csjoshi04 Jun 16 '16 at 07:38
  • To your second comment again, what will be application core in angular? (angular object??) Also what will the interface between module and application core? When we say modules should be decoupled from each other, then there has to be an interface for inter module communication. As per video sandbox should do that. Modules will talk to sandbox and sandbox will intern talk to application core. – csjoshi04 Jun 16 '16 at 08:02
  • In my case I created a core module that defines an API through services. All application modules will depend on the core, but aren't allowed to speak directly with their sibling modules. Every module is composed of services and directives. When you face a case where you would like one module to access a service of one of it's sibling modules then you refactor to put that service in the core. Finally, I'm abstracting most third-party libraries behind services that will expose only the features being used, unless it's not pragmatic for some reason. – plalx Jun 16 '16 at 12:39
  • You may define core sub-modules if you wish and application modules should be allowed to depend on them as well. – plalx Jun 16 '16 at 12:41

0 Answers0