Breeze suitability in a SPA Architecture Questions

Question

Please stick with me as this question may be long! We're currently in the process of architecting and prototyping a web based app where I work. It's a big app with a lot of intricacies and complexities and a lot of data.

Front-end technology wise, we are going to be building a SPA using Durandal, Knockout and TypeScript (to write all our JavaScript and jQuery code).

The back-end has been very carefully thought out and architected. Simplified, we will have a suite of application services (using nHibernate, AutoFac and others) that will be using a carefully designed domain model. A WebAPI will then use the methods in the application services to present the data back to the front end.

An obvious thought when building a SPA with a lot of DB interaction is to consider Breeze. There are a lot of well documented reasons why Breeze is brilliant. The problem is, we're not sure it fits in our architecture. None of us have used Breeze beyond some simple prototypes so if anyone can help answer the following questions, we would be very grateful!

1 - Are we correct in assuming that using Breeze by default would bypass our business logic and go directly to nHibernate or the DB? If this assumption is correct, are there ways to bypass it? Any advice / links? Our thought was that we would have to write an adapter for Breeze to route through to our business logic and provide the metadata back to Breeze. This then presents other issues like having partially and fully hydrated models in different parts of the system, projecting foreign keys. This is quite a contentious issue for us!

2 - One of the many reasons for using TypeScript is to give us static typed objects with intellisense. Are we correct in assuming if we used Breeze, we wouldn't have this out of the box?

3 - We don't want any caching at all. Is it possible to completely switch off this part of Breeze?

4 - If we're not using the querying feature (we're definitely not, we have a plan for searching that means using the Breeze querying feature alongside it is not an option), we're not using the caching feature and we can put things in place (such as a T4 template to automatically generate the TypeScript objects from DTO's) to help with the speed of development and reduction of code that Breeze can allow, are we negating the point of using Breeze?

I have done lots of searching, but all I can find is why Breeze should be used. While I admit it's fantastic, from my understanding so far, I'm just not sure it fits our app. Any advice or recommended reading will be greatly appreciated. With Breeze being fairly new on the scene, I'm struggling to find much information!

Answer 1

1) You can intercept any query or save within Breeze on the server. For saves this is done with the BeforeSaveEntities and BeforeSaveEntity override-able methods on the ContextProvider. For queries this is done simply via custom code in the server side endpoint methods. Both of these techniques are described in the Breeze documentation and there are are examples in the DocCode sample within the Breeze zip.

2) We have customers who are using Breeze with Typescript and using the Breeze metadata to generate Typescript class definitions. We plan on making a version of this kind of code available for general consumption at a later date. (We currently offer consulting support for Typescript related tasks. Please contact us at [email protected]. )

3) We plan on offering a noTracking option to the next version of Breeze, out within a month. Currently this same effect can be reproduced simply by performing a a "projection" query.

4) There is no issue with using your own query system with Breeze. See the discussion of "namedQuery" in the Breeze docs. You can even mix and match if you wanted to where the basic query could be augmented by additional client side filtering.

To your larger point. If you do not plan on using any caching or any of the breeze query enhancements then Breeze is probably not a good fit.

However, the cache's value is something you really need to evaluate. It is likely you will need to recreate this functionality yourself if you ever plan to

1. Run your app in a disconnected fashion. This includes serialization and deserialization from local storage.

2. Reduce roundtrips between client and server for data that has already been retrieved. This can be a major performance improvement for your app as it gets bigger.

3. Ability to query against just what's in memory on the current machine.

4. Automatically hook up graphs of entities that are related to one another when retrieved individually.

5. Change tracking and the ability to revert an entity to its originally queried state.

There are several other issues as well that I'm a bit too lazy to enumerate.

Hope this helps!

Answer 2

I approve of Jay's answer and will pile on. Jay didn't mention it but there is support for NHibernate now.

I have no problem with anyone skipping the IQueryable support. Breeze is cool about that. You can still use the breeze EntityQuery to hit any GET endpoint and pass it parameters if you like; and that's before you go "advanced" and start tweaking the ajax adapter.

Or you can use whatever AJAX apparatus you like to retrieve/save data and weave breeze into your process. In a release coming soon it will be even easier to merge JSON data into cache as entities no matter how you acquired those data.

Many will choose a hybrid approach in which they use vanilla breeze for the easy stuff like reference lists which tend to dominate the API. But they'll switch to custom approaches for the critical "20%" of the API that needs special treatment.

I'd love to know why you don't want to use the caching at all. I get why you might not want it for some queries. But never?

You realize that your client side data is out of sync with the server the moment you receive it. It's really just a matter of time. Caching prolongs the time during which the data can become progressively stale. But it's already rotting the moment it leaves the server.

A cache isn't forever. You can refresh individual entities in cache anytime. You can clear the cache anytime. And do both as often as you like depending on the volatility of the data or perhaps in response to notifications from the server (a sideband thing you might do with SignalR).

Full blown entities in cache are indeed essential to experiencing many of the benefit of Breeze:

• easily share common data among multiple views
• expose the current state of the entity data (including validation error messages) across views.
• track dirty state (EntityState.Modified)
• automatic validation when a property changes
• navigate to related entities: order.lineitem[0].product.name
• shrink query payload, thanks to self-assembling entity graphs (i.e., when Breeze receives the data for a queried product it automatically builds the navigation properties to the product's related reference entities such as shipper, manufacturer, productType, and productPricing ... assuming these are all in cache.
• revert pending changes
• query the cache
• stash changes locally and restore along with the preserved change state.

You can have as many distinct caches as you need, each with its own lifetime.

Remember ... you control the cache.

So what have you got against the cache?

Answer 3

Keeping a fresh cache

Your comment on Oct 31 reminds me that you can keep a resource minty fresh AND use the cache. It's not "either / or" !

Just do the following:

1. Always re-query that resource before using it (e.g., when your ViewModel loads the View)
2. Clear the cache of all instances of that resource type before you issue that query.

You can encapsulate both thoughts in your datacontext.getXXX method. Here's what I mean:

// get fresh invoices, optionally filtered, after clearing the cache of invoices
function getInvoices(optionalPredicate) {
    clearCachedInvoices();
    var query = breeze.EntityQuery.from('Invoices');
    if (optionalPredicate) { query = query.where(predicate); }
    return manager.executeQuery(query).then(_logSuccess, _queryFailed);
}

// refresh a specific invoice
function refreshInvoice(invoice) {
    // Todo: add parameter error checking?
    var query = breeze.EntityQuery.fromEntities([invoice]);
    return manager.executeQuery(query).then(success, _queryFailed);

    function success(data) {
        _logSuccess(data);
        return data.results[0]; // queries return arrays; caller wants the first.
    }
}

function clearCachedInvoices() {
    var cachedInvoices = manager.getEntities('Invoice'); // all invoices in cache
    // Todo: this should be a function of the Breeze EntityManager itself
    cachedInvoices.forEach(function (entity) { manager.detachEntity(entity); });
}

Important Caveats about cache clearing

The reason I'm clearing the cache first is that another user may have deleted some of the invoices that you previously retrieved. I assume you want them removed from your cache so that the user sees only the living invoices.

You won't need this cache clearing step (and the attendant concerns) if invoices can't be deleted (e.g., you did "soft deletes" instead by marking invoices "inactive"). I personally am deeply wary of deletes as they cause all kinds of problems. I prefer soft deletes.

It's up to you to make sure that the UI is not holding on to previous invoice entities. You've asked the manager to start fresh. That means every existing invoice entity reference is referring to a detached entity. After the query, every cached invoice is a new instance.

The other danger of clearing the cache is that it wipes out all pending invoice changes. You don't want to run this method if you could have unsaved invoice changes (new, update, or scheduled deletes). You might want to add guard logic to prevent the loss of unsaved changes. Exactly what that logic is will be application specific. It will likely involve a call to manager.hasChanges('Invoice').

You don't have to worry about lost references if you always refresh everything pertaining to invoices.

These constraints should be easy for you to fulfill. They align pretty much with what you said originally: you really didn't want to cache. So this should be a piece of cake ... just use the code shown above and you get the benefits of caching with little pain.

Ah ... but I can't help thinking about the person who actually WANTS to refresh the entity objects rather than replace them completely. Maybe she wants to refresh while users have unsaved changes. And yet she wants to remove entities that have been deleted by another user.

Well I have a recipe for her too.

function refreshAllInvoices(removed) {
        // removed is the caller's array that should be filled with the entities 
        // that we remove from cache; it's populated in the success method below.
    var cached = manager.getEntities('Invoice'); // get all invoices in cache
    return breeze.EntityQuery.from('Invoices')
                 .using(manager).execute(success, _queryFailed);

    function success() {  
        removed.length = 0; // clear the array  
        var results = data.results; // results from query
        // remove each result from the 'cached' array
        results.forEach(function (entity) {
            var ix = cached.indexof(entity);
            if (ix > -1) { cached[ix] = null; }
        });
        // what's left must have been deleted on the server
        // or is a new entity we haven't saved yet
        // Loop through, detaching the ones we think have been deleted.
        cached.forEach(function (entity) {
            if (entity !== null &&
                !entity.entityAspect.entityState.isAdded()) {
                removed.push(entity); // let caller know about this one
                manager.detachEntity(entity);
            }
        });

        return results;
    }
}