1
votes

I've been experimenting with breezejs lately and was considering using it for a number of projects both personal and at work since I love it. I know all the rage right now is with Single Page Apps and I get it, but let's say you didn't want to introduce a new routing framework and were comfortable just using .NET MVCs default routing engine. You will lose the client side caching capabilities of breeze's entity manager for the Metadata and other entities every time there is a POST/Redirect.

One of the issues is we have a large set of Metadata (.5mb) coming down for each request made. Now if there any additional requests on the client side before redirect then that metadata is cached and everything is fine. I'm trying to avoid the need to download the metadata for each view in addition to static lists that I would also cache in the entity manager. I know the metadata could be optimized by making smaller object graphs but let's not focus on that.

The one thing I came up with is to store the metadata in localStorage then retrieve it on page load.

function exportMetadata() {
   var metadata = emanager.metadataStore.exportMetadata();
   window.localStorage.setItem('somename', metadata);
}
function importMetadata() {
   var metadata = window.localStorage.getItem('somename');
   var mstore = new breeze.MetadataStore();
   mstore.importMetadata(metadataFromStorage);
   manager.metadataStore = mstore;
}

While this works (and will work for static lists with different syntax) it feels hacky and seems to go against how the library was meant to be used. I can't help but think that BreezeJS is coupled to the SPA architecture to utilized all of it's features as written. Maybe I'm thinking about it the wrong way? Are there any suggestions or examples of how to use BreezeJS outside a SPA?

1

1 Answers

2
votes

Breeze is intended for single page apps (SPAs) which are presumed to have long user sessions between page refreshes. I'm not sure why you don't want a client-side routing framework (e.g., Durandal or Angular). But it surely does happen that you'll want to switch pages from time to time.

That is even a recommended practice when you're application is really a confederation of smaller, modular apps - each developed and maintained independently - and the user crosses the "bridge" from one module to another.

Your solution is exactly what I would have done: stash and restore the metadata from browser local storage. You can combine that with stashing/restoring metadata and (mostly) static reference list entities in a single serialized cache ... as you say.

Adopting this practice is not hacky at all IMO. We intended Breeze to work this way. In fact, it's a great way to get faster launch-and-load times for "regular" SPAs.

I'd love to know why you think this is "hacky". I'm as interested in your thoughts about what Breeze could do for you w/o this practice. What would be the ideal world?