Patterns For Large-Scale JavaScript Application Architecture

Today we're going to discuss an effective set of patterns for large-scale JavaScript application architecture. The material is based on my talk of the same name, last presented at LondonJS and inspired by previous work by Nicholas Zakas. To continue reading the complete post, click here.


  1. Pingback: | jQuery & JavaScript Articles For The Community | A SQL Query walks into a bar, approaches two tables and asks 'Can I join you?'

  2. Pingback: Elegant D » Patterns For Large-Scale JavaScript Application Architecture

  3. There isn't much material as well thought out as this post. It's a shame that there isn't lively discussion on the subject. Thank you for taking the time to gather all this knowledge.

    Because I agree with all of it I'm finding it hard to even comprehend the alternatives and I would love for someone to post some.

    Also based off the propositions in the post which Javascript frameworks are the closest to this model?

    • That's a very interesting question. So far, we've been implementing the pattern using home-grown code specific to projects, but I'll be reviewing all of the different frameworks (particularly MVC ones) shortly and will post back (either in a comment or other post) about how I think they would best fit in the overall architecture proposed. Thanks!

  4. Excellent article! Just one question, where in the mediator architecture would a js mvc framework like backbone.js sit? or are they mutually exclusive?

  5. Great post. I'm curious about how you propose to manage the security side of things. In what way do you envisage the facade determining which modules can subscribe to which messages?

    • There are quite a few different ways in which security through the facade could be implemented and I plan on documenting this further at some point. One approach is maintaining a pattern for the published notifications coming from modules so you're able to easily tell where they originated (eg module1_newMessageReceived, module1_messagesAddedToPendingQueue).

      Here, you can easily perform a lookup against 'module1' to find out what permissions you've defined for it. Module permissions can be stored in any way you're comfortable with, but a simple JSON or multi-dimensional configuration array containing a list of modules and the permissions (as properties) they can perform would enable easy enough testing against.

      So, in pseudo-code: detect notification origin => perform lookup for permissions allowed for origin => check request from notification => if (request requires permissions outside of those allowed) => block, otherwise permit.

      • Sounds good. I guess it might get a little more tricky if you wanted to have two or more modules of the same type on a page. You'd either have to repeat the permission settings for each instance or perhaps also include a module type in your notifications so you could assign permissions by type or id? E.g. moduleType1_moduleId1_newMessage…

  6. In the publish method of the mediator pattern you have this line of code:

    subscription.callback.apply(subscription.context, args);
    Which makes sense, since the context needs to be kept when calling the method.

    Later in the code you give an e.g. of using it "via third party mediator" and you add the subscribe and publish methods to that specific object: "mediator.installTo(obj);"

    This is where i'm getting a bit confused. When you add that methods to the object "obj" you are basically just making a reference to them, right? they are not a copy.

    Then why if i replace in the publish method this line:, args);
    with this one, args);
    calling console.log(this); inside the object "obj" still referrs to object "obj". Whereas it should refer to the mediator object.

  7. Thank you for the great post, and elaborating on how one might implement security in the Facade layer.

    One thing I am unclear from Nicholas and your architecture is how the Mediator/Core layer knows how to request remote data. I understand that the Mediator/Core is responsible for issuing a remote call, via Ajax, JSON-P, etc but how does it know which url to request?

    For example, if I have a StockTicker module and it makes a 'getCurrentPrice' call to the Facade layer with a stock symbol. Who's responsibility is it to know which service to contact and how to contact that service (JSON-P, Ajax)?

    It seems that you want to keep the Mediator/Core pretty dumb and you don't want the StockTicker module to know about remote requests. My best solution so far is to handle this with another javascript module like ETradeStockService and interject this module into the Mediator/Core level as a plugin during the wiring up of all the modules. This allows me to add a different service down the road. It also means this service must adhere to a common Stock model when passing this data onto the StockTicker module, since the StockTicker module shouldn't know how to handle different data structures from different services.


  8. Question:
    How do you decide how much of the compute logic you want to push to the browser. For Eg in Google Spreadsheets are all calculations send to the server or some of them work on the client as well.

    • I think performance benchmarking really plays a big role here. Ideally, most calculations should be done on the client-side/in the browser without the need to push data back to the server in order to compute a result. That said, if you find that computing results (based on the complexity of the work involved) is so great that it's taking longer than acceptable when done in the browser, that's the point where I would shift those calculations server-side. It's something to be considered on a case-by-case basis.

      • Thanks Addy
        Amazon is offering a GPU compute node for high performance web applications. Would love see a sample architecture and design patterns to leverage this.

        Purdue university has that houses tons of nano-engg apps but delivered to the client via VNC. So you use those applications as a remote desktop application. The user experience is really awful. U can see two mouse pointers, one pointer following your mouse. every click takes a split second to register etc.

        A better way is needed.

Leave a Reply

Required fields are marked *.