Why does HotTowel include Breeze?

Question

This may sound like a dumb question on the surface, but why does the Hot Towel SPA Template include Breeze at all?

I've been spending the last few days learning Hot Towel and its dependencies, and as far as I can tell, nothing in the template actually uses Breeze. Perhaps that is going to change with some future release?

Sure, Breeze is a good library. But it's bound to CRUD methodology and requires you design your ApiControllers a particular way. (Metadata, SaveChanges, etc.) see here

It also guides you to Entity Framework. While this is more of a soft-dependency, since Breeze also shows a sample without it, it still guides you down a similar pattern of implementation using a modified repository pattern.

If you are using a NoSQL datastore, or CQRS patterns instead of CRUD, then Breeze becomes very difficult to use. There are alternative libraries for data access that work well in this style, such as AmplifyJS.

But the rest of Hot Towel is excellent! I especially like Durandal. So the question begs, if the template isn't actually doing any data access - why include any data access component at all? It would be better to ship it without Breeze, and if the end-user wants to use Breeze, or Amplify, or whatever - then so be it. The rest of Hot Towel would continue to shine as a great SPA implementation.

Quahog

Answer 1

Matt - Good question. Since I created it I guess I should answer :)

When I built the template I had a focus on providing enough to get folks going with the right tools, and just enough starter code to guide the way. I did not want anyone ripping out code. I'm not a fan of templates that start you down a path and make you remove tons of files and code and change direction. Those are samples.

Samples are good. In fact, samples can be excellent (like the other templates, which I feel are more like samples). Those serve another purpose: to show how you can do things.

Back to the Hot Towel template ...if I include code that uses Breeze, I would be tempted to add a datacontext.js and a model.js on the client. They would contain data access code and code to extend the models on the client. Then I would be tempted to add a controller, some server side models, an ORM and a database. Once there, I'd want to use the data in multiple screens, which leads me to more Knockout and caching with Breeze. Then I might be tempted to add editing, which would lead to change tracking. Soon I have a full blown app. Or more conservatively, I have a sample again. While these approaches would provide more guidance on how to put these together, they would not help you "get started" with a template where you can just start building and adding your own code. If I stop short of some of these features, it's still walking down a road that requires you to change how I did it.

As it stands today, HotTowel is pretty darn close to a template in the truest sense. You create a new project and you are off and adding your own code.

You could argue (and you may be) that Breeze shouldn't be in there since I don't use it in the template. Nor do I use moment.js, BTW. However, I argue that they are both excellent libraries that I would not want to build a CRUD based SPA without them. Breeze is flexible, as you suggest, so you don't have to walk a specific path.

The best way to understand the value of Breeze is to build an app that has its features but without Breeze. Then you can see how much code that takes and how involved it is. For one such example, see my intermediate level SPA course at Pluralsight where I do exactly this: http://jpapa.me/spaps

So you ask "why Breeze?" ... because I strongly recommend it for building a SPA.

Thanks for asking and good luck !

Saritasarkaria

As a side note ... Amplify, while fantastic, doesn't come close to what Breeze does. – Saritasarkaria

Thanks for the detailed answer. I guess I am using Hot Towel more like a sample starter than a template. I see your points though. For me, Breeze gets in the way since I already have a rich WebAPI to connect to. For others, perhaps it is better. You did a great job at wiring up Durandal and the Hot Towel shell is superbly crisp. It was fairly easy for me to replace the parts I didn't want, so it's all good. Seriously - it saved me a LOT of trouble. Thank you!!! – Quahog

Glad it is helpful. I am considering creating a template that is more of a sample. if it is helpful and there is enough interest, I'll do it. – Saritasarkaria

@JohnPapa I would certainly be interested. I've just started using asp.net and have played around quite a lot with Hot Towel (I have some experience with C# but quite a bit with Java which helps) and have found it very useful. However, it would be quite nice to see some different ways of using hot towel while referencing data. The only ways I have seen have been with breeze, using which I keep running into the OData not found error. One thing I would certainly like to see would be usage of an auto-generated MVC controller with views working alongside the MVVM model of hot towel. – Scanlon

@John Papa, I pushed my team to use BreezeJS for a WebAPI + OData backend and I am really sad about that decision. The support for OData in Breeze is not something you would like. Not entirely fault of the team but then there is not enough documentation around it to stop you from using it in the beginning. We found all workarounds for EDM model incomplete. There is lack of support for expand clause when he EDM is not fully supported and the team as beginners on Breeze struggled to use it easily. Part 1/2 – Estragon

part 2/2 contd. We had much simpler scenarios and mostly direct CRUD operations since we spent a good amount of time on finalizing the object model on server side. Still the niggling issues caused us a lot of burning the night oil. I am looking forward to their v4 support since the Odata V4 in Web API is much better compared to earlier. – Estragon

@Estragon I'm sorry you struggled with OData and Breeze. As an author of Breeze I can't really disagree. If we could fix it we would. But OData in Web API has been a nightmare from the beginning and they still haven't got the v.4 support where it should be for production apps. We documented some of this (here and here), trying to be as blunt as we could without offending. In general, I wouldn't use Web API OData if I could use plain old Web API. – Thibault

P.S.: We intend to offer Web API OData v.4 support when they get it right. – Thibault

@Thibault thanks for replying. We did manage to complete our project despite the challenges just this week but I will be looking forward to v4 support. In the meanwhile can you recommend/ point to way to cache the metadata from WebAPI? It is really easy with json. For our app, breeze calls $metadata before every request which slows down the performance. – Estragon

Hemant: Please ask your metadata question as a separate S.O. question. The short of it is that you can arrange to get your metadata ONE time or ZERO times from the web api. – Thibault

Answer 2

Thanks for asking the question.

John, as author of HT, has offered an answer. I, as a principal of the Breeze project, am inclined to agree with him :)

HotTowel generates a foundation for you to build upon. It is not the building itself.

It is a foundation intended for a specific kind of application, a CRUD application based on a specific set of cooperating JavaScript and ASP.NET technologies. Breeze is a contributor ... but not the only one. Knockout, with its MVVM design and 2-way data binding, is particularly well-suited to the data-entry tasks typical of CRUD apps.

Of course there are other kinds of SPAs. There's an important class of apps that mostly present information and accept little user input. Such apps don't benefit as much from data binding and the people who write them can get pretty hostile about data binding in general and KO in particular.

My point is that HT targets a particular class of application ... one that happens to be immensely successful at least when measured by sustained popularity. It delivers the goods for people who build those apps. It may not be the right starting place for other kinds of apps.

It is true that the easy road to Breeze runs through Web API, EF, and a relational database. Take those away, and you may writing more code on the server (and a little more on the client). That may be the perfect trade-off for you.

The authors of Breeze would like to make that path easier. I don't think BreezeJS makes it harder. I don't understand your statement "Breeze becomes very difficult to use." Have you tried it?

Your client can communicate with any HTTP resource in any manner you chose. It is pretty easy to use existing Web API controllers (albeit easier with Breeze Web API controllers). You can use amplify.js if you prefer (btw, you can tell Breeze to make AJAX calls with amplify). You don't even have to use the Breeze EntityManager to query and save data if you don't want to.

The rest of BreezeJS may still have value for you. There remains plenty of work to do after you've figured out how you'll retrieve and store data and whether you prefer Entity-ChangeSet style or Command/Query style.

You'll have to find answers to these questions:

• How will you shape the raw JSON data into bindable objects?
• How will you hold on to these objects and share them across multiple screens without making redundant round-trips to the server?
• How will you navigate from one object to a related object as you do when binding an Address to a combobox of StatesAndProvinces?
• How will you track changes?
• How will you validate them?
• How will you store some or all of the data in local storage when the app "tombstones"?

Breeze can help with these chores even if you don't want it to query and save for you.

And if you're answer remains "I'll do all of that myself, thank you" ... well, removing Breeze from your HotTowel project is as easy as:

Uninstall-Package breeze.webapi

Thibault

I would love to see a Breeze sample tie into some existing Web API controllers ... perhaps Matt and Ward can take a look at that together. It would be interesting to see the results. – Saritasarkaria

Thanks for your viewpoint. Yes - I have tried breeze, and I agree it has tremendous value for particular types of applications. The client library is great. The parts I have issues with are all on the server side. IQueryable with OData is great, but SaveChanges() & MetaData() are too proprietary for my liking. I am still going to attempt to adapt the NoDb sample for RavenDB, but it feels a bit limiting on the surface. I hope to prove myself wrong. :) – Quahog

Another point - I want to be able to use the same WebAPI endpoint both to build my own app, and to give my customers a developer SDK for connecting to my back-end server. My app shouldn't have any special access, and I don't want to force others to use breeze. They might be on some other platform entirely. Maybe there's some pattern for reconciling this that I haven't thought of? – Quahog

I hear you loud and clear. Please continue your own investigations while I rustle up some internal attention to these issues. I know you are not alone. – Thibault

Just to add in my few cents. I recently asked an SO question along these lines... I indicated that the SavesChanges method, while making life super easy, is somewhat proprietary. I agree that MetaData is also this way. Update 2 and webapi odata support has changed things quite a bit. You guys should seriously consider ContextProvider like boilerplate code that fits a lot better with webapi odata IMO. I want to see individual Put/Post/Delete methods like EntitySetController provides an abstract framework for... – Matisse