JavaScript data access design

Question

I'm writing a single page app and have made it to writing the data access layer for the client-side. My question involves the proper design of it. While I do understand JS is callback-centric, I have to wonder if there's not a better way to do data-retrieval. Here is an example of how my current data access calls are formatted with callbacks:

$interface.getDashboard = function (callback) {
    callback({MyApplications:[]});
};

Here is what I'm thinking of moving towards to eliminate the need for callbacks all over the place:

$interface.getApplications = function () {
    var v = amplify.store("api.applications");
    if (!v) {
        v = [];
        _get("/api/applications", null, function (results) {
            amplify.store("api.applications", results, { expires: _cacheTimeOut });
            dataRefresh();
        });
    }

    return v;
};

In the code above, dataRefresh() will tell all applicable subscribers to refresh their data. So I guess you can say it's still using callbacks but in a different manner.

Is there a better way to do this? I've never written a strong data access layer for javascript before and would like to know if there's a pattern to follow as convention or a heuristic solution perhaps?

Answer 1

I'm currently dealing with the same questions on how to design and structure the Javascript side of a new enterprise level application I'm working on.

Many of the SPA examples/templates such as HotTowel are great for showing you how to get started with SPAs, but do not give much help in terms of large scale implementation.

This talk by Nicholas Zakas proposes a great solution. Slides for the talk can be found here.

To summarise, your client side layers should consist of:

1. A set of modules - these provide discrete units of functionality for your app. They should be completely independent of one another and only be aware of the sandbox.

2. A sandbox - this provides a consistent facade interface for the modules to work with, and acts as a controller between the modules and the application core.

3. The application core - this is the mediator responsible for module management, intercommunication, and any other core functionality required by your app (e.g. ajax requests). Only the application core should be aware of the base libraries you are using.

4. Base libraries - these provide browser normalisation and any other general purpose functionality such as DOM manipulation.

This link expands on this design and provides some more detail.

I know this answer doesn't specifically address your data access layer, but as a more general architecture overview maybe you can apply the concepts to your particular scenario.

Edit:

AuraJS is a concrete implementation of the theories outlined by Zakas, developed by Addy Osmani. It's currently in developer preview but it looks like a great starting point for ideas.