1
votes

I've been reading about and playing with Breeze.js for a while, and it seems really awesome, but I have one concern: Server-side caching.

I can understand the advantage of caching entities client-side, but for a high traffic site, that doesn't seem like enough.

If I have a Companies table and my app is caching that client side, that's all well and good, but if I have 10,000 users hit my site for the first time all at once, that's still 10,000 hits to my database, as opposed to a single database call for that first user if I'm caching it on the server.

As far as I can tell Breeze only really works when you're accessing your database directly like this. I can imagine an OData service in between my database and Breeze client-side that handles the caching, but I imagine this would involve a ton of extra infrastructure in my code, specifically around getting the metadata to the client.

Am I wrong in assuming Breeze.js doesn't play well with server-side caching by default?

1

1 Answers

2
votes

The good news is that server-side caching is a fine option. Remember that Breeze is a client-side technology that works well with any resource that speaks HTTP and JSON. It doesn't have to be a database.

Metadata isn't a problem at all. Our Metadata documentation describes several techniques for treating metadata as the static resource it is. For example, you can easily JSON-ify it as a JavaScript file and import it on the client; put that JavaScript file on your CDN.

It's your server API. Caching certain high use, low volume collections (e.g., those pesky reference values that fill drop boxes) would be a piece-of-cake in Redis.

As with ANY server-side caching strategy, you have to plan for which collections to cache, where to go after a cache miss, and how to deal with updates.

I wish I had the time to draft a sample. Maybe you'll give it a try and share with the rest of us.