Breeze is free and open source through the MIT license.
Just because Breeze is free and open source doesn't mean that you're on your own. We sell support packages to ensure you have the help to succeed.
If you want to build your app really fast, contact our Professional Services team.
BreezeJS is a pure JavaScript library for building Single Page Applications in HTML and JavaScript. Technically, the server technology does not matter. Breeze works with any server capable of delivering data in response to an HTTP request. The server could be running Microsoft's ASP.NET. Or it could be running node, Rails, PHP, Java. BreezeJS neither "knows" nor "cares."
But we understand why you might think otherwise.
What databases does Breeze support? What about NoSQL databases like MongoDB?
Any standard SQL database like Oracle, MySQL, MariaDB, SQLServer, etc is supported out of the box as long as there is an Entity Framework Provider for it (and almost all of them do).
Breeze supports MongoDB, and for other NoSQL databases Breeze exposes a lower level IQueryable interface that allows querying these databases through a LINQ provider. Many of the most common NoSQL databases have such a provider. Saves to NoSQL databases are more complicated and do require customized code for each NoSQL database. We can provide these server side adapters as part of our consulting services.
What browsers does Breeze support?
Breeze works out-of-the-box with all modern browsers on desktop and mobile devices. These browsers implement the current JavaScript standard, known as ECMAScript 5 (ES5), which Breeze uses internally.
Older browsers (such as IE 8) implement the prior ES3 standard. Fortunately, you can enable ES5 syntax on these browsers by adding a JavaScript "shim" library to your page. See the Prerequisites topic for more details and a specific list of supported browser versions.
Where can I learn more about Breeze?
Where can I learn more about building SPAs (Single Page Applications)?
One of the best places to learn about building SPAs is John Papa’s Pluralsight video course “Single Page Apps with HTML5, Web API, Knockout and jQuery”. He explains and demonstrates many valuable tools and techniques that you’ll use in your application.
He didn’t use Breeze … because it wasn’t available at the time. However, John Papa is preparing a new SPA course using Breeze called Code Camper Jumpstart. See John's blog to learn more.
Can you add multiple entities on the client (like new customer, new order, new order details) and then save in bulk across the wire?
Yes. You can add a variety of entities to the cache and they can all have different operations pending. For example, you could have added a new order line item to an existing order, deleted a line item, and modified the ship date to the order. So you have three entities (one Order, two LineItems) in three different states (new, deleted, changed). You call saveChanges() and they all go up to the server together as a single change-set. Assuming the server plays along, it saves them as a single transaction.
Will Breeze manage the relationship on the client even though you have no key value yet?
Yes. Breeze supports a variety of store-generated key strategies out of the box and you can add your own. Assume for example, that Order has an integer identity key. Breeze assigns it a temporary key while in cache. All of the related LineItems have that temporary value in their “OrderID” foreign key (these property names can be whatever). After save, the permanent ID comes down to the client inside the Order (and the LineItems). If there were another unsaved entity that referred to that Order (perhaps saved only some of the changed entities), Breeze will fix-up that entity’s FK value to match the new permanent ID.
Are there caching options like expiration?
No. This is an important difference with server side caching. A server side cache does not have to worry about lingering references to cached data. When it evicts something, it doesn’t break any references. The next request for that thing results in a refetch; no biggie.
It’s different on the client where state lasts a long time and there are many possible consumers of the same entity at any one time. If we arbitrarily evicted an entity, we’d break whatever other object (a ViewModel?) had a reference to it and expected it to be alive in cache.
That said, you have complete control over the cache. If you know what the lifetimes of the entities are, you can evict them. You can make as many caches as you like so you can sandbox data into different workflows and manage them separately.
It’s easy to refresh an entity or a collection of entities at any time without breaking the object references or removing them from cache. So you could set up your own MRU or refresh timer policy for refreshing periodically … or evicting old stuff if you know it is safe to do so.
It would be cool to hook up to something like SignalR to learn about server-side changes (e.g., truck changed location, new order arrived, etc.), and respond to that signal with a refresh.
Can I store the cache contents somewhere (semi-) permanently?
Yes. The cache manager, called the EntityManager, can export all or a portion of its cache contents as a serialized string … which you can then store wherever you like. Reimport that string to re-populate that EntityManager … or any other EntityManager. We have a couple of examples of storing to browser local storage and restoring from there to a new EntityManager.
Will it take advantage of HTML5 validation if present, so we don't have to manually add attributes?
We assume you are hoping to avoid adding all of those HTML validation attributes that put validation logic in your HTML instead of in your model.
We're looking at the “Custom Validation” section of Stephen Walther’s post on HTML 5 Validation for reference where he attaches an event listener to an element and calls setCustomValidity with the error message. You could use that technique to pass through to the Breeze validator for the corresponding model property and let Breeze apply all of the appropriate validations for that property and forward its error messages to the UI.
Apparently the Knockout Validation library does something like this. We will explore options for integrating Breeze and HTML 5 validation in the near future. Stay tuned.
How smart is the self-tracking? Can it differentiate between an add, insert, delete?
Yes. Each entity has an EntityState enum in the set {Added, Modified, Deleted, Unchanged, Detached}. If the entity was changed, you have access to the origina” values for the properties that changed.
Can you integrate with mock data libraries?
We mock up entities all the time when testing and demonstrating Breeze features. We throw entities into the cache that we make appear to have been queried from remote storage by changing their EntityState to “Unchanged”.
Because you query the cache with the same query object that you’d use to query the server … and we always run ViewModel logic through a dataservice/repository layer … it’s easy to redirect queries to the in-cache fakes rather than the server.
Note also that we can keep this cache of fakes in an EntityManager that is separate from the one used by the application workflow. So the results of a query against this Cache-‘O-Fakes can be poured into your working EntityManager as if they had come over the wire. Copying entities between EntityManagers is trivial. Faking the save is only slightly more difficult.
You’d still have to map the results of a mocking library (say, mockJSON) into entities. That shouldn’t be hard … no harder than creating entities with fake data by hand. Hope to have an example in the coming weeks. But why should you wait? All the better if you beat us to it. Let us know if you need help.
Free & open source
