SignalR is a library for adding real-time web functionality to applications. It uses web sockets, server-sent events, and long-polling to enable real-time functionality between a server and client browsers. SignalR supports cross-platform connections from JavaScript and .NET clients to any backend. Hubs provide a simple abstraction for defining real-time endpoints and handling connections that can scale across servers. A backplane like Redis can be used to enable real-time connections across servers for scaling out applications. SignalR can also be self-hosted outside of IIS.
An introduction to SignalR
This deck was part of my presentation to Virtusa employees on an ASP.NET asynchronous, persistent signaling library known as SignalR
There is also a slide on how to use SignalR with SharePoint.
Date: August 2013
Follow / Tweet me: @ShehanPeruma
A modified version of my Desert Code Camp 2011.2 presentation on SignalR from November 5th, 2011.
It's modified since I'm more of a talker and rarely utilize bullet points and much text in my slides.
Deep diving SignalR with ASP.NET MVC 6.
Speaker: Mr Sherman Chen - Telerik Senior Architect/Advocate with more than 15 years developing desktop, web and mobile apps
Creating responsive and interactive web applications has always been one of my hidden dreams. One of the biggest show stopper has been the communication between server and clients. The rise of websockets now open some space for a brand new kind of applications; but we need a library that makes things 'easy' for us and that is able to fall back on previous solutions when the latest technologies are not available.
Suddenly on the ASP.NET scene appears SignalR: a persistence connection abstraction library that helps ASP.NET developers deal with 'real time' client-server communication sceneries.
Real time websites and mobile apps with SignalRRoy Cornelissen
My session about building real time websites and mobile apps using the SignalR framework. Delivered on Microsoft TechDays Netherlands 2013.
In this session I combined a back end in NServiceBus, a SignalR ASP.NET gateway, and WPF, WinRT and iOS clients (using Xamarin.iOS) to build a real time production monitor.
This presentation aggregates common approaches of real-time client-server communications provided by Web Standards. It focuses on comparison of different techniques like polling, comet, Web Sockets, Server-Sent Events.
Real time web applications with SignalR (BNE .NET UG)brendankowitz
Static web pages and data don't cut it anymore. Information online is real-time and even web applications should respond to continuous changes. As SignalR has recently been introduced as a component to the ASP.NET runtime there's no better time to start building web application that respond to change. SignalR does all the heavy lifting and makes it easy to introduce into a wide range of projects, so pry your application out of the static mould and start responding to the real dynamic nature of information and changes as they occur.
A brief overview of the significance of API Gateways in microservices architecture by providing Kong as an example.
Slide 2: Monolith Vs Microservices
Monolith:
Pros-
Simple to implement
Less integration test - easy to test
Easy to ship
Fast development
Cons-
Violates Open-Close principle
Nightmare when it comes to managing the code
Difficult to enhance
Bigger artifacts
Hard to replace individual components like DB, Logger etc.
Microservices-
Pros-
Easy to manage
One reason to change
Dynamic scaling
Single responsibility
Cons-
Multiple points of failure
Hard to test - rich integration tests required
Heterogeneity in infrastructure
Slide 3: API Gateway Pattern
It is microservices design pattern.
An API gateway is a service which is the entry point into the application from the outside world. It’s responsible for request routing, API composition, and other functions, such as authentication.
There are a lot of issues when client is talking to multiple components to get the job done. These include multiple proxies at client side, different logic to handle different calls, client needs to know the implementation details of server.
A much better approach is for a client to make a single request to what’s known as an API gateway. An API gateway is a service which is the single entry-point for API requests into an application. It’s similar to the Facade pattern from object-oriented design. Like a facade, an API gateway encapsulates the application’s internal architecture and provides an API to its clients. It might also have other responsibilities, such as authentication, monitoring, and rate limiting.
These are also termed as BFF - Backend For Frontend
Slide 4: API Gateway in Action
It acts as a “backend for the frontend”. The clients do not know which services they are talking to. They communicate with a single interface - API Gateway. The gateway resolves the client requests and distributes them to respective services.
Slide 7: Kong Architecture
Kong is a cloud-native, fast, scalable, and distributed Microservice Abstraction Layer (also known as an API Gateway, API Middleware or in some cases Service Mesh). Made available as an open-source project in 2015, its core values are high performance and extensibility.
Actively maintained, Kong is widely used in production at companies ranging from startups to Global 5000 as well as government organizations.
An introduction to SignalR
This deck was part of my presentation to Virtusa employees on an ASP.NET asynchronous, persistent signaling library known as SignalR
There is also a slide on how to use SignalR with SharePoint.
Date: August 2013
Follow / Tweet me: @ShehanPeruma
A modified version of my Desert Code Camp 2011.2 presentation on SignalR from November 5th, 2011.
It's modified since I'm more of a talker and rarely utilize bullet points and much text in my slides.
Deep diving SignalR with ASP.NET MVC 6.
Speaker: Mr Sherman Chen - Telerik Senior Architect/Advocate with more than 15 years developing desktop, web and mobile apps
Creating responsive and interactive web applications has always been one of my hidden dreams. One of the biggest show stopper has been the communication between server and clients. The rise of websockets now open some space for a brand new kind of applications; but we need a library that makes things 'easy' for us and that is able to fall back on previous solutions when the latest technologies are not available.
Suddenly on the ASP.NET scene appears SignalR: a persistence connection abstraction library that helps ASP.NET developers deal with 'real time' client-server communication sceneries.
Real time websites and mobile apps with SignalRRoy Cornelissen
My session about building real time websites and mobile apps using the SignalR framework. Delivered on Microsoft TechDays Netherlands 2013.
In this session I combined a back end in NServiceBus, a SignalR ASP.NET gateway, and WPF, WinRT and iOS clients (using Xamarin.iOS) to build a real time production monitor.
This presentation aggregates common approaches of real-time client-server communications provided by Web Standards. It focuses on comparison of different techniques like polling, comet, Web Sockets, Server-Sent Events.
Real time web applications with SignalR (BNE .NET UG)brendankowitz
Static web pages and data don't cut it anymore. Information online is real-time and even web applications should respond to continuous changes. As SignalR has recently been introduced as a component to the ASP.NET runtime there's no better time to start building web application that respond to change. SignalR does all the heavy lifting and makes it easy to introduce into a wide range of projects, so pry your application out of the static mould and start responding to the real dynamic nature of information and changes as they occur.
A brief overview of the significance of API Gateways in microservices architecture by providing Kong as an example.
Slide 2: Monolith Vs Microservices
Monolith:
Pros-
Simple to implement
Less integration test - easy to test
Easy to ship
Fast development
Cons-
Violates Open-Close principle
Nightmare when it comes to managing the code
Difficult to enhance
Bigger artifacts
Hard to replace individual components like DB, Logger etc.
Microservices-
Pros-
Easy to manage
One reason to change
Dynamic scaling
Single responsibility
Cons-
Multiple points of failure
Hard to test - rich integration tests required
Heterogeneity in infrastructure
Slide 3: API Gateway Pattern
It is microservices design pattern.
An API gateway is a service which is the entry point into the application from the outside world. It’s responsible for request routing, API composition, and other functions, such as authentication.
There are a lot of issues when client is talking to multiple components to get the job done. These include multiple proxies at client side, different logic to handle different calls, client needs to know the implementation details of server.
A much better approach is for a client to make a single request to what’s known as an API gateway. An API gateway is a service which is the single entry-point for API requests into an application. It’s similar to the Facade pattern from object-oriented design. Like a facade, an API gateway encapsulates the application’s internal architecture and provides an API to its clients. It might also have other responsibilities, such as authentication, monitoring, and rate limiting.
These are also termed as BFF - Backend For Frontend
Slide 4: API Gateway in Action
It acts as a “backend for the frontend”. The clients do not know which services they are talking to. They communicate with a single interface - API Gateway. The gateway resolves the client requests and distributes them to respective services.
Slide 7: Kong Architecture
Kong is a cloud-native, fast, scalable, and distributed Microservice Abstraction Layer (also known as an API Gateway, API Middleware or in some cases Service Mesh). Made available as an open-source project in 2015, its core values are high performance and extensibility.
Actively maintained, Kong is widely used in production at companies ranging from startups to Global 5000 as well as government organizations.
Session: A Reference Architecture for Running Modern APIs with NGINX Unit and...NGINX, Inc.
Building and deploying cloud native APIs is a complex operation, and can require a multitude of components. In this workshop we focus on the fundamentals of deploying the runtime API code and publishing the API through an API gateway. To achieve this we use NGINX Unit as a polyglot application server and NGINX web server as an API gateway. With this combination we deliver a solution lightweight enough for dev and strong enough for production.
You will learn how to use NGINX Unit to run one or more apps and APIs in a variety of languages, including seamlessly deploying new versions. You will then see the best practices for how to configure NGINX to perform the common API gateway functions of request routing, rate limiting, and authentication for multiple APIs. We will also touch on advanced use cases such as HTTP method enforcement, and JSON validation.
No previous experience of NGINX or NGINX Unit is required, but a basic knowledge of HTTP and JSON/REST APIs is valuable.
Being a WordPress developer means that our main programming language is PHP. Which works for building websites but not for running tasks. In this talk I will share my experience using Node.js as a platform to build on. Explaining why I have chosen for Node.js and show you how I used Node.js to build microservices that are supporting my WordPress projects.
AWS as platform for scalable applicationsRoman Gomolko
Introduction to Amazon Web Services that allow to concentrate on your application rather then concentrating on infrastructure needed to run. Following services are briefly exposed Beanstalk, RDS, DynamoDB, DynamoDB streams, Kinesis, SQS, Lambda, S3, CloudFront.
JUDCon 2013- JBoss Data Grid and WebSockets: Delivering Real Time Push at ScaleC2B2 Consulting
JUDCon 2013 Presentation by Mark Addy, C2B2 Senior Consultant- JBoss Data Grid and WebSockets: Delivering Real Time Push at Scale
The real time web is coming with WebSockets in HTML 5. The big question is how to deliver event driven architectures for WebSockets at scale. This session delivered by the experienced middleware consultant provides an insight on how combining JBoss Data Grid with WebSockets can deliver enterprise scale push to web devices. The session first provides an introduction to WebSockets and delves into typical JBoss Data Grid architectures and how they deliver linear scalability and high availability. We then look at the event capabilities inherent in JBoss Data Grid that when hooked up to a WebSockets server can deliver data grid updates in real time to HTML 5 mobile devices.
Developing Revolutionary Web Applications using Comet and Ajax PushDoris Chen
Join the asynchronous web revolution! Because Ajax-based applications are almost becoming the de facto technology for designing web-based applications, it is more and more important that such applications react on the fly, or in real time, to both client and server events. AJAX can be used to allow the browser to request information from the web server, but does not allow a server to push updates to a browser. Comet solves this problem. Comet is a technology that enables web clients and web servers to communicate asynchronously, allowing real-time operations and functions previously unheard of with traditional web applications to approach the capabilities of desktop applications. This session will start to provide an brief introduction to the asynchronous web, AJAX polling, long polling, and Streaming, explaining the Bayeux protocol, Cometd, Grizzly Comet implementation on GlassFish. Different approaches and best practices to develop comet application will also be discussed. You will learn how to develop the chat application, how to implement distance learning slideshow application, how to manage a chat application from the server and how to develop a two-player distributed game application. Attendees will take away the tactics they need in order to add multiuser collaboration, notification and other Comet features to their application, whether they develop with Dojo, jQuery, jMaki, or Prototype and whether they deploy on Jetty, Tomcat, or the GlassFish Application Server.
SenchaCon 2016: A Look Ahead: Survey Next-Gen Modern Browser APIs - Shikhir S...Sencha
Using modern browsers, developers can now create web apps with capabilities that were only possible in native or hybrid apps. Web apps can now access hardware devices such as microphones, cameras, GPS, accelerometers, VR displays, and many others, without using any plugins. Using Web Bluetooth, web app developers can now communicate with nearly any type of hardware device. In this session, we’ll survey a sample of the W3C standards that give developers access to next-gen capabilities via web apps. Topics will include Service Worker, Push API, WebRTC, Web Bluetooth, Web Crypto, Web Speech, Web Notifications, and others.
SenchaCon 2016: How to Give your Sencha App Real-time Web Performance - James...Sencha
Learn about the options for giving your Sencha app real-time web performance. We begin with a review of the HTTP and HTML5 technologies available to the Sencha developer (AJAX Long Polling, Server Sent Events, and Web Sockets). We will then look at a ready-made JavaScript framework, SignalR, which makes it simple to integrate real-time capabilities into your Sencha app. Finally, we cover some design lessons learned during the development of our product, AquaRemote, for maintaining a consistent user experience when real-time data updates are required over unreliable cellular data networks.
It will describes SOAP/REST differences and SOAP web services in detail with practical approach. it shows usage of SOAP, XML, JAVA, WSDL, XSD and RPC with examples.
3. Intro to SignalR
• A library for real-time web functionality
• Built on OWIN(SignalR 2.x)
• Open Web Interface for .Net
• Open source on Github
4. Intro to SignalR
• Built on persistent connections
• Remote Procedure Call(RPC)
• Server push
• Transports
• Web Socket
• Server Sent Event
• Forever Frame
• Long Polling
• Fallback
8. Server Sent Event
• HTML5 EventSource
• One way communication
(Server to client)
• Except IE
9. Web Socket
• Persistent full-duplex
bi-directional connection
• Criteria are met for both
server and client side
10. Web Browser Transport Requirements
Transport
Internet
Explorer
Chrome
(Windows or
iOS)
Firefox
Safari
(OSX or iOS)
Android
WebSockets 10+ current - 1 current - 1 current – 1 N/A
Server-Sent
Events
N/A current - 1 current - 1 current - 1 N/A
ForeverFrame 8+ N/A N/A N/A 4.1
Long Polling 8+ current – 1 current - 1 current - 1 4.1
12. Core Architecture
publisher
message cache
worker worker worker
client client client client client
message bus
1.Message serialized,
saved to cache
associated with signal,
topic is marked for
delivery, publish call
returns
2. Worker is scheduled for
a signal, selects a waiting
subscriber, retrieves
message from cache
3. Worker sends message
to client as bytes over a
transport
13. Watch out
• Sending large messages
• Memory leaks – all hub instances are transient
• Session – don’t use it from SignalR, at all, ever (no support)
14. Platform Support
• OS
• Windows 2008 r2 to 2012
• Windows 7+
• Windows Azure(No support Web Socket)
• .Net framework
• .Net 4.5+(Web Socket support)
• .Net 4
• IIS
• IIS 8(Web Socket support)
• IIS 7 and IIS 7.5
15. Hubs
• Least developer work
• Monitor network transport
• Specifying network technology
• Accept/Return simple type, complex type
• Complex objects serialized to/from JSON
16. Hubs-Server side
• Register in Startup.cs
• HubName attribute
• Broadcast
• Clients.All.dynamic
• Clients.Caller.dynamic
• Clients.Others.dynamic
• Clients.Caller(Context.ConnectionId).dynamic
• Clients.AllExcept(connectionId, connectionId).dynamic
• Clients.User(userId).dynamic
PM> Install-Package Microsoft.AspNet.SignalR
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
app.MapSignalR();
}
}
[HubName("alias")]
public class NewHub : Hub
{
}
20. Hubs
• Groups
• Send message to particular groups
• Not persisted on server
• Server side
• Groups.Add(Context.ConnectionId, groupName)
• Groups.Remove(Context.ConnectionId, groupName)
• Broadcast
• Clients.Group(groupName).dynamic
• Clients.Group(groupName, connectionId,
connectionId).dynamic
• Clients.OthersInGroup(groupName).dynamic
23. Scale out + Backplane
Backplane
clien
t
Server
clien
t
clien
t
clien
t
clien
t
clien
t
Server
clien
t
clien
t
clien
t
clien
t
clien
t
Server
clien
t
clien
t
clien
t
clien
t
24. Backplane
• HOW TO
• Nuget + ONE line code
• Limitation
• Much slower than single server
• Lower rate
25. Load patterns
• Server broadcast – low rate, message to all clients
• Server push – low rate, message to unique clients
• User event driven – broadcast on client action
• High frequency – fixed high rate, unique messages
26. Backplane
• Redis
• SQL Server
• Azure Service Bus
PM> Install-Package Microsoft.AspNet.SignalR.Redis
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
app.MapSignalR();
}
}
GlobalHost.DependencyResolver.UseRedis("server", port, "password",
"AppName");