Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Für alle: Leichtgewichtige Architekturen mit ASP.NET Web API & SignalR

Für alle: Leichtgewichtige Architekturen mit ASP.NET Web API & SignalR

Die Entwicklungen vor allem rund um mobile Anwendungen und Devices sowie Cloud Computing bedeuten für viele Softwareprojekte ein Umdenken, vor allem in der Architektur. Wer das heute ignoriert, könnte sich morgen in Kalamitäten befinden. Wie bekomme ich eine leichtgewichtige Integration meiner Systeme mit interoperabler Kommunikation gestemmt? Wie kann ich Daten von meinen Services mittels Real-Time-Web-Kommunikation in meine Clients hinein pushen? In diesem Vortrag wird Christian Weyer aufzeigen, wie man diesen neuen Anforderungen architekturell begegnen kann. Dabei kommen Frameworks wie ASP.NET Web API, SignalR oder das neue ASP.NET 5 zum Einsatz.

Christian Weyer

September 20, 2016
Tweet

More Decks by Christian Weyer

Other Decks in Programming

Transcript

  1. 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 Web Technologies • [email protected] • @christianweyer 2
  2. Central question J • How to move our Windows Forms

    or WPF or UWP app to mobile devices and to the browser?
  3. 5

  4. 6

  5. 7

  6. 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 9
  7. 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“ • Web/HTTP („REST“, anyone?) – fully embrace HTTP – least common denominator technologies – less functionality (KISS?) – reach and interoperability said to be better – „easier to use“ 13
  8. 16

  9. Distributed Application Architectures for Modern Applications • Reach vs. rich

    • Base foundation vs. features • Light-weight vs. heavy-weight 17
  10. 18

  11. HTTP – the Application Protocol • Application protocol • URIs

    • Verbs • Headers • Content types • Content negotiation • Status codes 19
  12. 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 20
  13. 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<T> – Actions expose explicit DTO data, HttpResponseMessage or JsonValue / dynamic 21
  14. 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 22
  15. 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 23
  16. 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 24
  17. 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 25
  18. 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 26
  19. 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 28 Push Service Consumer Send data External event (Database) External event (Message queue) External event (Other actor) Notify [data]
  20. 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 30 Server Client
  21. 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? 31
  22. 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 32
  23. 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 33
  24. 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 – Write hub class – Add route in host process – Done 34
  25. 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 35
  26. 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 36 public void SendMessage(string message) { var msg = string.Format("{0}: {1}", Context.ConnectionId, message); Clients.All.newMessage(msg); }
  27. 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 37
  28. 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’ 38
  29. jQuery without Proxy File • Late binding approach • Simple

    steps to get going – Create hubConnection • Derived from $.connection – Get dynamic proxy – Wire up events based on method/event handler name via on – Start & invoke methods based on method name via invoke • Same connection-related event handlers • Cross-domain support same as with static proxy 39 var connection = $.hubConnection(); var proxy = connection.createHubProxy('chat'); proxy.on('newMessage', onNewMessage); connection.start(); proxy.invoke('sendMessage', $('#message').val());
  30. .NET Client • Client NuGet package contains binaries for all

    supported .NET flavors • Mental model resembles proxy-less JavaScript approach • Simple steps to get going – Create HubConnection – Create hub proxy via CreateHubProxy – Wire up event handlers via On – Start connection with Start – Call methods via Invoke 40 var hubConnection = new HubConnection("http://localhost/services"); var chat = hubConnection.CreateHubProxy("chat"); chat.On<string>("newMessage", …); hubConnection.Start().Wait(); …
  31. Hosting • Hosting sits on top of OWIN – IAppBuilder

    API • Simple steps to get going – Define startup class with IAppBuilder method signature – Map hubs onto IAppBuilder (route) • In ASP.NET: Startup class used in WebApplication.Start to spin up server – HTTP or HTTPS base URL 41
  32. 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 42
  33. Resources • [email protected] • http://www.thinktecture.com • Demo with Web API,

    SignalR and AngularJS 1 – https://github.com/ChristianWeyer/WebApiSignalRAngularDemo • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib • ASP.NET SignalR – http://www.asp.net/signalr 43