Christian Weyer | Thinktecture AG Für alle Leichtgewichtige Architekturen mit ASP.NET Web API & SignalR

Christian Weyer • Co-founder, co-owner and principal consultant at Thinktecture AG • Focus on – Mobile & web-based application architectures – Interoperability, cross-device – Pragmatic end-to-end solutions • Microsoft MVP for ASP.NET (Architecture) ASP.NET Web API / vNext Advisory Board Member ASPInsider, AzureInsider • Google GDE for AngularJS • http://blogs.thinktecture.com/cweyer christian.weyer@thinktecture.com @christianweyer 2

Architectures for… • Enterprise • ISV • Web • … any difference today? 3

4

5

Modern Business Applications Reach!

Ubiquitous Access • .NET clients • Silverlight clients • Pure HTML(5) • JavaScript & jQuery • Android (Java) • iOS (Objective-C) • Embedded (C/C++) • Java • Any client, any device, actually 7

8

No content

Web/HTTP APIs with ASP.NET Web API

Architectural Approaches to Service Orientation • „SOAP“ / WS-* – transport protocol independent – „secure, reliable and transacted“ (WS-*) – sophisticated and complex protocol stack – interoperability may become difficult – „the best RPC so far“ – „on the web, not of the web“ • Web/HTTP („REST“, anyone?) – fully embrace HTTP – least common denominator technologies – less functionality (KISS?) – reach and interoperability said to be better – „easier to use“ 11

Which one is ‚better‘? 12

Which one is more ‚polite‘? 13

14

Distributed Application Architectures for Modern Applications • Reach vs. rich • Base foundation vs. features • Light-weight vs. heavy-weight 15

16

HTTP – the Application Protocol • Application protocol • URIs • Verbs • Headers • Content types • Content negotiation • Status codes 17

Web API Framework Requirements • Need a first class HTTP programming model • Easily map resources to URIs and implement the uniform interface • Rich support for formats and HTTP content negotiation • Separate out cross cutting concerns • Lightweight, Internet scale • Realize REST-ful or RPC-ish architectures – Being pragmatic, not idealistic 18

Implementing a Web API • ASP.NET Web API technology stack – Based on OWIN • Derive from ApiController • Implement your actions – Actions map to HTTP methods – Prefix method name with desired HTTP method – e.g. PostComment – Use [HttpGet/Post/Put/Delete] if you prefer a different name – Supports async with Task – Actions expose explicit DTO data, HttpResponseMessage or JsonValue / dynamic 19

Hosting & Clients • Several hosting options, e.g. – ASP.NET Web Application (IIS) – Self-host server option (console application, Windows service, etc.) • HttpConfiguration defines behavior • OWIN as base for hosting Web API, SignalR etc. • HttpClient is a cross-.NET HTTP client API • JavaScript: jQuery’s $.ajax, or $http in AngularJS 20

Routing • Maps a URL space to your Web API controllers – {controller} + “Controller” • Can be tailored using actions, default values and route constraints – Like more RPC-ish behavior • Alternative: attribute-based routing – Defines routes with .NET attributes 21

Working with HTTP • “First class experience” for using HTTP – exposing HTTP as an application protocol in its full glory and not hiding it • Use of HttpRequestMessage and HttpResponseMessage – way of giving direct access to the HTTP protocol, without parsing and encoding complexity • Use IHttpActionResult – Better testability; pre-defined action results 22

Model Binding & Formatters • Model binding can “shred” the request and bind it to individual parameters • Values are taken from the URL (route variables, query parameters) or from the body • MediaTypeFormatters are used to deserialize the request body based on the content type – XML, JSON, form-url-encoded supported out of the box • Request data is validated as it is bound to the parameters 23

Content Negotiation • Response format is determined based on HTTP content negotiation • Request Accept header expresses desired format(s) • Server selects a format for the response based on the request and the available MediaTypeFormatters • Help/documentation page optionally available at /help • Use Swagger for open documentation standard 24

Push Services with ASP.NET SignalR

Push Services Pattern • ‘Push Services’ are really not an official pattern – Observer pattern, anyone? • Model a service that – accepts incoming connections from callers – is able to push data down to callers – abstracts from communication nitty-gritty details • Realize Publish-Subscribe semantics – Based on standard web technologies with reach in mind – With maximum reach into any device, platform Push Service Consumer Send data External event (Database) External event (Message queue) External event (Other actor) Notify [data] 26

Technical Approaches for Push • Periodic Polling • Long Polling – HTTP Streaming / Comet 27

Long Polling Poll but don’t respond untill there’s data • Server holds on to the HTTP request until there is data to return • (Re-)Poll after data received or after the connection times out • Consumes server threads & connection resources Server Client 28

Technical Approaches for Push • Periodic Polling • Long Polling – HTTP Streaming / Comet • Forever Frame • Server-Sent Events (SSE) • Web Sockets • Easy: Web Sockets are the way to go! – Only with Windows 8/Server 2012 – Network considerations – Maybe some time, but not today • Alright, let’s just write code for any technology & technique! – Erm… really? For any server and any client platform? 29

ASP.NET SignalR as a Solution • SignalR is – a server-side framework to write push services – a set of client libraries to make push service communication easy to use on any platform – optimized for asynchronous processing • Abstracts from the different techniques to implement pushing data – Mental model is a persistent connection – Volatile, non-durable • ‘Signal’, anyone? – Sending data to a signal. E.g. represented by a connection ID • Part of the ASP.NET brand, but not tied into ASP.NET runtime and APIs 30

ASP.NET SignalR Development • Extensible framework & pipeline – Based on interfaces & DI • Two programming models – Persistent connections – Hubs • Hubs offer a pre-defined application-level protocol in an RPC-ish style – Easy-to-get-going means for 80/20 situations 31

Hubs Concept • Hubs are classes to implement push services in SignalR – Abstraction on top of persistent connection – Convention-over-configuration • Hubs provide a higher level RPC framework – Perfect for different types of messages to send between server and client • Hub conventions – Public methods are callable from the outside – Send messages to clients by invoking client-side methods • Simple steps to get going 1. Write hub class 2. Add route in host process 3. Done 32

Programming Model • Hub name reflected into external API – [HubName] can alias name • Return simple type, complex type or Task • Complex objects and arrays of objects automatically serialized/deserialized to/from JSON – Default is JSON.NET • Context holds connection- and request-specific information – ConnectionId – Request – Headers – RequestCookies – QueryString – User 33

Pushing Data: Clients • Clients property as dispatching point to send messages to clients • Holds dynamic properties and methods • Target method with parameters is dynamically ‘injected’ into code path, serialized, and embedded into response public void SendMessage(string message) { var msg = string.Format("{0}: {1}", Context.ConnectionId, message); Clients.All.newMessage(msg); } 34

Hub Consumers • Consumers can be classic client applications or other services/hubs • SignalR provides a variety of client libraries • Microsoft SignalR team – .NET 4.0+ – WinRT – Windows Phone 8 – Silverlight 5 – jQuery – C++ • Community – iOS native – iOS via Mono – Android via Mono 35

jQuery Client • HTML5-based applications often use jQuery • JSON-based wire protocol makes it easy to integrate with JavaScript • SignalR jQuery plugin offers two approaches – Proxy-based with generated proxy – Without proxy but ‘late binding’ 36

jQuery without Proxy File • Late binding approach • Simple steps to get going 1. Create hubConnection • Derived from $.connection 2. Get dynamic proxy 3. Wire up events based on method/event handler name via on 4. Start & invoke methods based on method name via invoke • Same connection-related event handlers • Cross-domain support same as with static proxy var connection = $.hubConnection(); var proxy = connection.createHubProxy('chat'); proxy.on('newMessage', onNewMessage); connection.start(); proxy.invoke('sendMessage', $('#message').val()); 37

.NET Client • Client NuGet package contains binaries for all supported .NET flavors – .NET 4.x, SL5 – WP8, WinRT • Mental model resembles proxy-less JavaScript approach • Simple steps to get going 1. Create HubConnection 2. Create hub proxy via CreateHubProxy 3. Wire up event handlers via On 4. Start connection with Start 5. Call methods via Invoke var hubConnection = new HubConnection("http://localhost/services"); var chat = hubConnection.CreateHubProxy("chat"); chat.On("newMessage", …); hubConnection.Start().Wait(); … 38

Hosting • Hosting sits on top of OWIN – IAppBuilder API • Simple steps to get going 1. Define startup class with IAppBuilder method signature 2. Map hubs onto IAppBuilder (route) • In ASP.NET: Startup class used in WebApplication.Start to spin up server – HTTP or HTTPS base URL 39

Summary • Flexible lightweight architectures – Based on the Web • Web APIs for exposing services with reach – ASP.NET Web API as lean technology stack • Push Services for implementing bi-directional communication – ASP.NET SignalR as enabling framework • Good base for a number of different application architectures – Web-based, native, Desktop, mobile 40

Resources • christian.weyer@thinktecture.com • http://www.thinktecture.com • Thinktecture’s GitHub Repositories – https://github.com/thinktecture • Christian Weyer’s GitHub Repositories – https://github.com/ChristianWeyer • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib • ASP.NET SignalR – http://www.asp.net/signalr 41