Herding Code: Herding Code 155 – Ward Bell on Single Page Applications and Breeze

Herding Code

On this episode of Herding Code, the guys talk to Ward Bell about single page applications and the Breeze project. Download / Listen: Herding Code 155 – Ward Bell on Single Page Applications and Breeze Show Notes: General SPA discussion Ward talks about how IdeaBlade has been building tools for w.

Running time
File size

Download Original File | View original post

Episode synopsis

On this episode of Herding Code, the guys talk to Ward Bell about single page applications and the Breeze project.

Download / Listen:

Herding Code 155 – Ward Bell on Single Page Applications and Breeze

Show Notes:

  • General SPA discussion
    • Ward talks about how IdeaBlade has been building tools for working with data in rich clients for a while, and after seeing the move towards desktop experiences in the browser they started the Breeze project, which is open source and free.
    • Jon asks Ward to define single page applications (SPAs) a bit, and Ward says he sees SPA as a funny term since it just describes one attribute of the experience – it’s like calling a car a “horseless carriage.” Ward says the goal is to give the user a rich experience and not rely on the server to deliver that rich experience. A lot of the value comes from maintaining data and state on the client.
    • There’s a discussion about the value and best applications of SPAs.
    • Kevin says there are a few aspects of SPAs – there can be a lot of individual, interactive pages which are separately delivered by the server, or you can have a more full application which handles screen transitions on the client. Ward talks about the tradeoffs of the two approaches. The whole SPA application approach is especially important in newer scenarios like mobile or Window Store applications built in HTML/JS.
    • Scott K asks about the different approaches to data loading – do you preload some of the data, or does the first page request just deliver an HTML client which requests all the data.
    • Scott K asks how often Ward sees offline manifests and local data. Ward says he sees things going that way, but it’s still early. Scott K and Ward talk about the difficulty of synchronizing offline changes when you’re reconnected.
    • Scott K and Ward talk about the use of Web Sockets and / or SignalR to handle locks to allow for multiple users.
  • Breeze
    • Jon asks Ward how Breeze helps
    • Ward says that they’re not trying to solve solved problems – they’re focused on solving the data problem.
  • Breeze, Upshot, and the ASP.NET SPA template
    • Jon asks how this fits in with the former ASP.NET SPA template and Upshot. There’s a discussion the history and state of Upshot and RIA Services.
    • Scott K asks about whether Upshot will be released as open source… or the unreleased ASP.NET MVC Recipes source. Jon starts crying.
    • Jon and Ward talk about how one of the big features of Upshot was that there were both client and server side parts to it.
    • Ward said they’d learned from the Upshot, so they made Breeze very extensible while making for an easy path when using ASP.NET Web API and Entity Framework.
    • Ward says the current ASP.NET MVC SPA app is too simplistic, because it’s just one simple screen.
  • Working with Breeze – client state, server-side interaction
    • Jon asks Ward about how Breeze handles local state. Ward describes how the server can send down metadata (likely from an Entity Framework model) to the Breeze client code so it can understand the models, relationships, validation rules, etc. You can extend things if you need to, but you don’t need to bother with the tedium of creating client models that match your server-side models.
    • The generated client-side models are ready to be hooked up to Knockout so they’re easily bound to the UI.
    • Jon asks how things are different on the server. Ward says that standard ASP.NET Web API controllers are very repetitive – each controller has GET, PUT, POST, DELETE methods that are just boilerplate. Pretty soon you end up with thirty API Controllers which just contain a lot of boilerplate code. Breeze can just expose things as Queryables so you really just need one controller unless you want to customize things. Scott K says it sounds like it’s basically Repository<T>. Scott K says he’d like to see it go further – at Cascadia there were some talks about big data where queries were created on the client and sent to the server.
    • Jon and Ward talk about the difficulties of complex repetitive APIs with too many entry points.
  • How Breeze fits in with other frameworks like Ember, Angular, Backbone, etc.
    • Jon asks how Breeze fits in with Ember, Angular, and other SPA frameworks. Ward talks about different framework philosophies and how Ember and Angular both more of top to bottom stacks. Kevin mentions how Backbone differs – it’s more of a library vs. a framework.
    • Ward says that Breeze really targets the data scenario. Jon asks how close its vision is to Upshot’s. Ward explains how, other than Ember Data, nobody’s looking at solving the data scenarios – they don’t worry about caching, object graphs, change tracking, etc. Scott K says the other frameworks are really MVC focused, so they don’t consider data.
    • Scott K asks what happened to Batman.js. Nobody knows.
    • Jon asks if the happy path for Ember is Rails focused and Breeze is ASP.NET / Entity Framework focused. Ward says yes, with a clarification that we’re really talking about Ember Data.
  • Getting Started
    • Jon asks if it’s difficult to get started with Breeze.
    • Ward talks about the NuGet package that gets a sample project set up quickly.
    • Ward talks about the live tutorial that lets you play with Breeze in a browser.
    • Ward talks about the automated tests they’ve got for Breeze training. Jon compares it to Ruby Koans.
  • Jon, Ward, Kevin and Scott K talk about automated JavaScript testing options – Chutzpah, QUnit, Jasmine, Mocha.
    • Chutzpah is an automated JavaScript test runner that can run inside of Visual Studio.
    • QUnit is pretty simple – tests are functions that take true or false.
    • Jasmine is more BDD style.
    • Mocha is a test framework that supports different front ends, so you can use BDD, standard unit testing, etc. It’s also got great async support.
  • Ward brings up TypeScript and Scott Koon starts cursing.
  • Wrap up small talk
    • Jon says that the talk about mocha reminds him of coffee, and he asks Ward about his new espresso machine. Jon and Ward both get their coffee beans from Sweet Maria’s.
    • Jon says he’s still roasting his coffee on his barbeque.
  • Scott K asks what dependencies Breeze has. Ward says they write to EcmaScript 5 and have gotten rid of all dependencies other than one called Q.
  • It’s time for Pimp Yo Stuff, and Jon takes the occasion to praise Ward’s sartorial skill. Scott K says they’d like to
    • Ward pimps the DevForce and and Cocktail combination. Cocktail is DevForce + Caliburn.Micro.
    • Jon asks about the license for Breeze. Ward clarifies that it’s all free and open source, and they make their money on support and professional services.

Show Links:

You might also like...



Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Weeks of coding can save you hours of planning.”