Herding Code 156: Catching up with Andreas Håkansson and Steven Robbins on NancyFx

The guys catch up with Andreas and Steve on what’s new in NancyFx (a web framework for .NET that was originally inspired by Sinatra).

Download / Listen:

Herding Code 156 – Catching up with Andreas Håkansson and Steven Robbins on NancyFx [audio:http://herdingcode.com/wp-content/uploads/HerdingCode-0156-NancyFx.mp3]

Show Notes:

  • Jon asks for a quick overview of NancyFx. Steve and Andreas both say you can write the same app on any number of web frameworks, so what really distinguishes them is the syntax and feel. Andreas says that the web only has a small set of things you really can do – there are only a few HTTP methods – but an infinite number of ways you can build applications; Nancy is one of them.
  • Diagnostics
    • Andreas says Diagnostics is a website built into Nancy itself. It covers things like request tracing and interactive diagnostics.
    • Steve explains how the interactive diagnostics lets you find out what routes were hit and why, poke at live code, etc.
    • Andreas says this works using companion classes for metadata which is then rendered via JavaScript templates, so you can customize it as much as you want.
    • Jon says the code for Diagnostics seems like pretty good sample code for getting an idea of how Nancy code works.
    • Jon asks about how authentication is handled to restrict access.
    • Steve says they’re using Handlebars for JavaScript templates with Backbone and Nancy on the back end.
  • Content Negotiation
    • Andreas explains how routes just return models, and the formatting is handled by response processors. There’s a syntax to allow for more control at the route level if needed.
    • Steve says the response processors are allowed to participate in the selection by specifying how applicable they are for both content types and model types. The content negotiation can also allow you to select different models based on the request, avoiding unnecessary code from executing and weighing the model down unnecessarily.
  • Serializers and dependencies
    • Jon asks about the JSON serializers they’re using, and why they’re not using something like ServiceStack or JSON.NET. Andreas explains that because the Nancy core ships without dependencies, they used Mono code.
    • Jon asks about where Nancy can be be embedded, outside of standard web hosting scenarios.
    • Steve says that because Nancy doesn’t have other dependencies and is strictly focused on returning a response for a request, it’s extremely easy to test.
    • Andreas points out that you can use other serializers very easily via a NuGet package.
    • Jon asks about how packages work in Nancy. Andreas explains how Nancy scans for classes that implement ISerializer.
    • Kevin asks about implementing a processor for generating hyperlinks between models.
    • Jon asks if people are sharing processors. Steve says that they’re so trivial to write that there’s no real point in sharing them.
  • Localization
    • Andreas says this was a community contribution. There are several conventions (including querystring values, URL segments) which can be used to set the culture for the context. There’s a helper on the Razor base class that returns a dynamic object which can return localized values from a resource. Assembly resources are used by default, but you can add others.
    • Steve says that you can also use localized views based on filename.
    • Jon asks for more information on how you’d set up a custom resource location.
  • Architecture, pipelines, and IoC
    • Jon says that he spoke with Jeremy Miller at Codemash, and Jeremy said that it took a while to get the processor architecture set up, but now it’s very easy to add in features. It seems like that’s also paid off for Nancy. Andreas agrees, the pipeline system and dependency injection really simplify adding in new features.
    • Jon asks about how Nancy uses TinyIoC and how you could use TinyIoC in other applications.
    • Kevin and Jon ask about how Steve wrote TinyIoC to run on multiple platforms. Steve describes some issues they’ve worked around and how assembly scanning can get tricky due to test frameworks injecting things into the app domain.
  • Non-standard uses of Nancy
    • Jon asks for some examples. Steve says they seen people embed it into WPF applications for an interface, to provide mobile support, and even on Raspberry Pi. They’d love to hear more about what people are doing with it.
  • Questions from Twitter / Misc. Questions
    • Jim Liddell (@liddellj) asks about the roadmap. Steve talks about work they’re doing for OWIN and Async support.
    • Filip W (@filip_woj) asks "Why tuples instead of classes and structs?"
    • Kristof Claes (@kristofclaes) asks "How do they determine when something is "too much ceremony"? Gut feeling? Set of defined rules? Talk? Compare to other FX?"
    • Ian Battersby (@Cranialstrain) asks "Why dynamic? And don’t say fluency ;)"
    • Tobi Tobsen (@t0bit0bsen) asks "Is there a NancyFx tutorial for devs w/o a background in web development or should they look elsewhere?"
    • Jim Liddell (@liddellj) asks "How do you view Nancy in relation to similar frameworks, such as OpenRasta?"
    • Kevin asks about asset management for Nancy. Steve says that’s probably better handled by external
    • Kevin asks about web socket support. Steve says just use SignalR.
    • There’s a Nancy store now.
    • Daniel Lee (@danlimerick) asks "How many hours a week do you spend on Nancy? What’s ratio of reviewing PR’s vs writing new features?"
    • Jon asks what Steve and Andreas are finding fun and interesting lately. Steve and Andreas both like Mongo.
    • Scott K. asks if they’ll add time zone localization support. They tell him to submit a pull request.

Show Links:

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

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 [audio:http://herdingcode.com/wp-content/uploads/HerdingCode-0155-Ward-Bell.mp3]

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: