Blue Gmail Modules all over the place.
Anyway, what these guys suggest is an underlying architecture that allows your entire application to be divided into “modules”, which you might want to think of as widgets. They are just separate parts of your application with functionality that is entirely separate from the rest of the application. If you look at Gmail, as an example, the left navigation, the main email list, the chat widget, the top navigation bar, etc. are all separate modules.
None of these modules should communicate directly with one another. They must be entirely independent of one another for the sake of loose coupling and scalability. This might confuse you because obviously, in Gmail, the left navigation communicates with the main email list in order to change what is shown there, but these two modules should not communicate directly.
Application Structure. Thanks to Nicholas Zakas.
Instead, everything communicates directly with what Addy and Nicholas call a sandbox. Essentially the sandbox utilizes two patterns: mediator and facade. The sandbox is a facade for the application core, which I’ll talk about a little later. It is also a mediator between all of the modules by using the observer pattern. Each module subscribes to different events via the sandbox. When a module does something that it thinks is interesting, it will publish it to the sandbox, and the sandbox will inform all of the other modules who were subscribed to that event so that they can act upon it.
The application core is what actually handles the subscriptions. The sandbox abstracts these subscriptions a bit. In Addy’s implementation, there is also a permissions object that specifies which modules can subscribe to which events and the sandbox combines the permissions and the application core for a single seamless interface to the rest of the application. Also, the application core abstracts the base libraries, such as jQuery or YUI and even the MVC libraries so that you can switch them out at a later date with minimal changes to the application.
In the image above you could see how the application core sits on top of the base libraries. That means that the core only knows about these libraries and does not know of the existence of anything else. The sandbox only knows about the application core. The modules only know about the sandbox. This limited knowledge of other components makes the application ridiculously extensible and limits the power of any one component to only what it needs to be able to do.
Here’s the best part of this article. Addy and a few others have worked on a project called Aura that brings these nuggets of knowledge into a real existence. You can find the documentation for Aura here and the actual GitHub project is here. I have yet to try it out, and the project is currently in “Developer Preview” stage (meaning it’s pretty much ready, but they haven’t done much testing and the docs are quite sparse). I’m considering adapting my Minecraft Server Manager to use this. I already have a plethora of changes to make to the app, at least on the front end, so it’s mostly ready for a complete overhaul anyway, so why not start over using this?
In short, we all thought we were being awesome by using MV* frameworks, but in reality large applications still need more if we want them to be scalable and extensible for the future. I think Addy and Nicholas have a great idea and we should try it out to either prove their ideas to be amazing or misguided. If you can find ways to improve on their techniques, I’m sure everyone in the community would love to hear about it, so let us know or let Addy or Nicholas know! God bless and happy coding.