Last year, I was looking into various ways of communication between client and server for one of my project work. Evaluated SignalR too as one of the options. I found decent documentation online to put across a test app to see how it works.
Introduction
SignalR is a free and open-source software library for Microsoft ASP.NET that provides ability to server-side code push content to the connected clients in real-time.
Pushing data from the server to the client (not just browser clients) has always been a tough problem. SignalR makes it dead easy and handles all the heavy lifting for you.
Most of the shareout online considers it as ASP.NET/Web application solution only which is not true. As mentioned in quote above, client could be a non-browser too like a desktop application.
I gathered that behind the scenes, SignalR primarily tries to use Web Socket protocol to send data. WebSocket is a new HTML5 API (refer my detailed article on it) that enables bi-directional communication between the client and server. In case of any compatibility gap, SignalR uses other protocols like long polling.
Using the SignalR Hub class to setup the server. Defined a hub that exposes a method like an end point for clients to send a message. Server can process the message and send back a response to all or few of the clients.
[HubName("TestHub")]
public class TestHub : Hub
{
public void ProcessMessageFromClient(string message)
{
Console.WriteLine($"<Client sent:> {message}");
// Do some processing with the client request and send the response back
string newMessage = $"<Service sent>: Client message back in upper case: {message.ToUpper()}";
Clients.All.ResponseToClientMessage(newMessage);
}
}
Specify which “origins” we want to allow our application to accept. It is setup via CORS configuration. CORS is a security concept that allows end points from different domains to interact with each other.
public void Configuration(IAppBuilder app)
{
app.UseCors(CorsOptions.AllowAll);
app.MapSignalR();
}
Server is setup using OWIN (Open Web Interface for .NET). OWIN defines an abstraction between .NET web servers and web applications. This helps in self-hosting a web application in a process, outside of IIS.
static void Main(string[] args)
{
string url = @"http://localhost:8080/";
using (WebApp.Start<Startup>(url))
{
Console.WriteLine($"============ SERVER ============");
Console.WriteLine($"Server running at {url}");
Console.WriteLine("Wait for clients message requests for server to respond OR");
Console.WriteLine("Type any message - it will be broadcast to all clients.");
Console.WriteLine($"================================");
// For server broadcast test
// Get hub context
IHubContext ctx = GlobalHost.ConnectionManager.GetHubContext<TestHub>();
string line = null;
while ((line = Console.ReadLine()) != null)
{
string newMessage = $"<Server sent:> {line}";
ctx.Clients.All.MessageFromServer(newMessage);
}
// pause to allow clients to receive
Console.ReadLine();
}
}
In above code, Using IHubContext:
Server is setup to have earlier defined Hub as one of the broadcast end point.
Server is also setup to broadcast any message to all clients by itself if needed be
Client is setup to communicate with the server (send and receive message) via hub using HubConnection & IHubProxy. Client can invoke the exposed end point in the hub to a send a message.
static void Main(string[] args)
{
string url = @"http://localhost:8080/";
var connection = new HubConnection(url);
IHubProxy _hub = connection.CreateHubProxy("TestHub");
connection.Start().Wait();
// For server side initiation of messages
_hub.On("MessageFromServer", x => Console.WriteLine(x));
_hub.On("ResponseToClientMessage", x => Console.WriteLine(x));
Console.WriteLine($"============ CLIENT ============");
Console.WriteLine("Type any message - it will be sent as a request to server for a response.");
Console.WriteLine($"================================");
string line = null;
while ((line = Console.ReadLine()) != null)
{
// Send message to Server
_hub.Invoke("ProcessMessageFromClient", line).Wait();
}
Console.Read();
}
With above setup, we can see the communication between Client & Server realtime like below:
Things to consider while opting for SignalR
SignalR looks awesome. But, there are couple of things one should know while using it:
It’s a connected technology – each client connected through SignalR is using a persistent and dedicated connection on the Web Server. SignalR is shared as scalable but it never harms to look for any queries around connections, memory, cpu, etc with higher number of clients.
One would need to setup a valid host server with a PORT open on it that can be used for communication. This could depend on an organisation security protocols and approvals.
Hope this gives a quick overview about SignalR. Keep learning!
I recently experimented with React.js, so thought of sharing key points that I learnt. Though there are handful of material online, couldn’t find one that covers all in a concise way that can help learn key aspects of ReactJS. I believe this would resonate with few and help them learn, understand and get a jumpstart with ReactJS.
What is React.js?
React.js is an open source JavaScript based library for building frontend (user interface) of a web or mobile application.
Why React.js?
Every web application core is to have a fast rendering response for better user experience. Because of this ease, users come back often and it leads higher usage and adaptability.
Further, based on how it achieves speed, it is scalable and reusable.
How React.js does it?
React.js works at component level. It helps break an app into many small components with their own responsibilities. This makes things simpler and scalable. With this breakdown,
it’s easier to refresh/update a portion of view without reloading an entire page of the app.
it leads to build once and reuse across.
Another key part of React.js is being declarative. There is a an abstraction from details on how to do. This makes it easier to read and understand.
A declarative example would be telling my son to make a house craft from paper instead of guiding him with each step of how to get the paper, cut it, paste it to form a house craft. Of course the assumption here has to be true that my son knows how to make it.
A quick comparison with jQuery here (it’s imperative) – it would need details on how to build the house craft.
Translating above in Javascript langauge world:
With React – we define on how we want a particular component to be rendered and we never interact with DOM to reference later
With jQuery – we would tell browser exactly what needs to be done using DOM elements or events need basis
Key features
Following features help us achieve above:
Components – Simple or State
These are small reusable codes that returns a React element to render. This component can have state related aspect based on need.
// Simple component - a Function Component
// props - input to React component - data passed from parent caller
function ComponentExample(props) {
return <h1>Hola! {props.name}</h1>;
}
// Simple component - a Class Component
class ComponentExample extends React.Component {
render() {
return <h2>Hola! {this.props.name}</h2>;
}
}
// State based component
// Needed when data associated with component change over time
class ComponentExample extends React.Component {
constructor(props) {
super(props);
this.state = {author: "Sandeep Mewara"};
}
render() {
return (
<div>
<h2>Hola! {this.props.name}</h2>
<p>Author: {this.state.author}</p>
</div>
);
}
}
For above example component, use normal HTML syntax: <ComponentExample />
Virtual DOM
DOM (Document Object Model) is a structured representation of the HTML elements present on a web page. Traditionally, one would need to get elements out of DOM to make any change. In context of an area of a webpage, it would need a lot more work to refresh it with updated content when needed.
React helps here with its declarative API. A copy of actual DOM is kept in memory which is much faster to change. Once done, React uses its ReactDOM library to sync the virtual representation of UI in memory to the actual DOM.
ReactDOM library internally keeps two VDOMs – one before update and one after. With them, React knows exactly what all to be updated in actual DOM and does all of it on the fly leading much faster updates compared to traditional DOM updates.
React.js has a library ReactDOM to access and modify the actual DOM.
To render HTML on a webpage, use:ReactDOM.render()
JSX (JavaScript eXtension)
JSX is a syntax extension to JavaScript that follows XML rules. It’s more of a helpful tool than requirement in React as mentioned below in their website:
React doesn’t require using JSX, but most people find it helpful as a visual aid when working with UI inside the JavaScript code
JSX converts HTML tags into React elements that are placed in DOM without any commands like createElements(), etc.
// Example with JSX
const testHtml = <h2>Hola! Sandeep Mewara</h2>;
ReactDOM.render(testHtml, document.getElementById('root'));
// Same above example without JSX
const testHtml = React.createElement('h2', {}, 'Hola! Sandeep Mewara');
ReactDOM.render(testHtml, document.getElementById('root'));
Normally, we can’t assign an HTML tag to a JavaScript variable but we can with JSX!
Unidirectional data flow
React implements one way reactive data flow. It uses flux as a pattern to keep data unidirectional. Interpret it as you often nest child components within higher order parent components. Snapshot of state is passed across from parent to child components via props (readonly, cannot be updated) and updates from child to parent happen via callbacks bound to some control on child component.
ES6 compatible
React library is ES6 (ECMAScript 2015 or JavaScript 6) enabled and thus makes it easier to write code in React. Among all changes to standardize JavaScript in ES6, Classes introduction is one of them which plays a critical role in React.
Lifecycle
Each React component has a lifecycle that helps write a code at a specific time during the flow as per need.
// Use class for any local state & lifecycle hooks
class TestClass extends Component
{
// first call to component when it is initiated
constructor(props)
{
// with it, 'this' would refer to this component
super(props);
// some local state initialized
this.state = {currentdate: new Date()};
};
// executes before the initial render
componentWillMount() {
};
// executes after the initial render
componentDidMount() {
};
// executes when component gets new props
componentWillReceiveProps() {
};
// executes before rendering with new props or state
shouldComponentUpdate() {
};
// executes before rendering with new props or state
componentWillUpdate() {
};
// executes after rendering with new props or state
componentDidUpdate() {
};
// executes before component is removed from DOM
componentWillUnmount() {
};
// HTML to be displayed by the component rendering
render()
{
return (
<h1>Current Date: {this.state.currentdate.toString()}</h1>
);
};
}
We will explore and understand more from React’s demo app. We will jump start our sample app bootstrapped with Create React App
I used yarn create react-app demo-react-app and opened the created directory in IDE that looked like:
With above, once I ran yarn start in root folder demo-react-app, app was up and running without any code change. We can see default app hosted in browser at following url: http://localhost:3000/
Quick look at few key files that connect dots that lead to above UI view:
public/index.html
Base file which we browse using url. We see the HTML defined in it. For now, the element to notice would be a div named root.
src/index.js
Located at root of app, is like an entry file (like main) for app that has code like below:
import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import * as serviceWorker from './serviceWorker';
ReactDOM.render(
<React.StrictMode>
<App />
</React.StrictMode>,
document.getElementById('root')
);
// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();
It imported React and related library, CSS file for app, a component named App. After this, it defines a render method which displays whatever is defined in component App as page root element.
src/App.js
Defines a function component of React that returns an html with React logo and a link to render.
import React from 'react';
import logo from './logo.svg';
import './App.css';
function App() {
return (
<div className="App">
<header className="App-header">
<img src={logo} className="App-logo" alt="logo" />
<p>
Edit <code>src/App.js</code> and save to reload.
</p>
<a
className="App-link"
href="https://reactjs.org"
target="_blank"
rel="noopener noreferrer"
>
Learn React
</a>
</header>
</div>
);
}
export default App;
How did index.js got connected with index.html?
Create React App uses Webpack with html-webpack-plugin underneath. This Webpack uses src/index.js as an entry point. Because of this, index.js comes into picture and all other modules referenced in it. With html-webpack-plugin configuration, it automatically adds the script tag in html page.
Let’s see with few modifications to the app now!
Specifically I will be changing flavour of above 3 files to play around.
AppHola.js file for a HelloWorld kind of change – displays my name instead of other texts
AppNavigation.js (has portion of pages updated)
Introduction – simple display of texts
Clock/counters auto updating
Random color generator that updates background color of defined area
Given this was for beginners, I have not added too much of complexity to the app. I have tried to keep it as simple possible with some variance of what all can be tried.
There are plenty of imports that can be used. For example, in our demo app, to have navigation, we have used a navigation router react-router-dom import (run npm i react-router-dom --save inside root folder).
Hope this short guide/tutorial gives a broad overview about React.JS and how to start development of the same. Keep learning!
Recently, we were working on a project that needed numerous HTTP requests to be made. Initial implementation had a new HttpClient object being created for every request being made. It looked to have some performance cost attached to it that led us to evaluate the effect of using single vs multiple instances of HttpClient.
Problem Statement:
Whats the best way to use HttpClient for multiple requests and the performance cost associated with it?
Assessment:
Went through the Microsoft documentation, which seemed updated based on last when I read few years back. Found a fineprint for myself that states:
HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.
This was a straight give away that we should use a single instance HttpClient – irrespective of a usecase, one would want to keep distance from SocketException errors (though probability of it would be high for heavy usage of HTTP requests).
Now, the query was how to have single HttpClient for multiple requests but with different request payload for the calls? Also, does this has any impact on performance of the calls and if so, how much?
Resolution:
I started with looking into performance aspect for the two options. Created a test application that helped evaluate the time taken for various number of requests. Tried with www.google.com but seems they have some kind of check at 1000 requests so went ahead with www.bing.com that looked uniform till 5000 requests that I tried with.
for (var i = 0; i < noOfConnections; i++)
{
using (var httpClient = new HttpClient())
{
var result = httpClient.GetAsync(new Uri("http://www.bing.com/")).Result;
}
}
//having private static readonly HttpClient _httpClient = new HttpClient();
for (var i = 0; i < noOfConnections; i++)
{
var result = _httpClient.GetAsync(new Uri("http://www.bing.com/")).Result;
}
With the above, I got the following numbers on an average post few runs:
No of Requests
Multiple Instance (s)
Single Instance (s)
%age Diff
100
20
16.67
16.65
500
103
88
14.56
1000
216
174
19.44
2000
430
351
18.37
5000
1032
906
12.21
It looked like the difference peaked around 1000 requests and overall there was an improvement with single instance.
Now, given we had a usecase where multiple HTTP requests has to be made simultaneously but with different payloads, looked at how to achieve it with single instance. Keeping multiple types of requests, unit testing, high load – One possible way looked like below that worked out well for us:
// Single instance of HttpClientManager was setup
public class HttpClientManager : IHttpClientManager
{
...
public HttpClientManager(HttpMessageHandler messageHandler)
{
_httpClient = new HttpClient(messageHandler);
}
private HttpRequestMessage SetupRequest(IRequestPayload requestPayload)
{
var request = new HttpRequestMessage
{
RequestUri = new Uri(requestPayload.Url)
};
switch (requestPayload.RequestType)
{
case RequestType.POST_ASYNC:
request.Method = HttpMethod.Post;
request.Content = GetHttpContent(requestPayload.ContentJson);
break;
case RequestType.PUT_ASYNC:
request.Method = HttpMethod.Put;
request.Content = GetHttpContent(requestPayload.ContentJson);
break;
case RequestType.DELETE_ASYNC:
request.Method = HttpMethod.Delete;
break;
case RequestType.GET_ASYNC:
request.Method = HttpMethod.Get;
break;
default:
request.Method = HttpMethod.Get;
break;
}
...
}
public HttpResponseMessage ExecuteRequest(IRequestPayload requestPayload)
{
HttpRequestMessage httpRequestMessage = SetupRequest(requestPayload);
HttpResponseMessage httpResponseMessage = _httpClient.SendAsync(httpRequestMessage, HttpCompletionOption.ResponseHeadersRead).Result;
return httpResponseMessage;
}
private HttpContent GetHttpContent(string contentJson)
{
return new StringContent(contentJson, ENCODING, MEDIATYPE_JSON);
}
}
Since there are numerous articles on the web explaining details of the entire HttpClient workflow and inner details, I will not cover that here but a quick explanation on couple of key info. In the code above:
HttpRequestMessage is used to setup HttpClient object based on our need. We make use of the fact that HttpRequestMessage can be used only once. After the request is sent, it is disposed immediately to ensure that any associated Content object is disposed.
Making use of HttpClient underlying implementation, have used HttpMessageHandler more from the unit test point of view.
Conclusion:
One should use a single instance of HttpClient at application level to avoid create/destroy of it multiple times. Further, results suggest this also has better performance with more than 12% improvement based on the load.
For multiple requests of different payloads, having a single instance HttpClient but a new HttpRequestMessage for every request looked a good approach to use.
Long time, since I have blogged. Specifically, this particular post – had all the details and wanted to post more than a year back. I guess, better late than never! Here are few of the HTML5 tips that might help while using it’s various features:
HTML5 WebSocket Protocol is present only from IIS 8.0
HTML5 Web Socket provides a two-way communication over one TCP connection (socket). IIS 8.0 (ships with Windows 8) is capable of accepting Web Socket communications. In order to use the new protocol, one has to enable it in IIS 8.0, using option “Turn Windows features on or off” present in the control panel. It should look like below: A quick detail on how WebSocket works can be looked here in my article: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#websocket
One can support new HTML5 elements in older browsers using HTML5 shiv
Older browsers that are still widely used by end users (namely IE6/7/8) do not have support for the new elements in HTML5. One great way to enable HTML5 element support in IE6/7/8 is to have the http://code.google.com/p/html5shiv/ As noted on the linked Google page, “shiv” and “shim” are interchangeable terms in this context. In case interested, I came across a good sample example and details out here: http://www.sitepoint.com/html5-older-browsers-and-the-shiv/
Elements in HTML5 can easily be made draggable
The specifications defines an event-based mechanism – a JavaScript API and additional markup for declaring it. Any type of element can be marked draggable on a page. It’s a known fact that having a native browser support for a particular feature is best as they would be faster and provide a more responsive application. A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#dragdrop
‘Type’ attribute for script and link are no more required in HTML5
Type attribute is optional and one does not need to provide it for script and link tag in HTML5. Earlier, one used to give:
This makes things simpler as the file extension and the tag were enough to interpret the type.
async attribute has been added to <script> tag in HTML5
HTML5 has added a new attribute for <script> tag, which is async. With this attribute, the external script will be executed asynchronously as soon as it is available. It has no effect on inline scripts. Inline scripts and scripts without async or defer attributes are fetched and executed immediately, before the browser continues to parse the page.
In HMTL5, all unknown element in all browsers are displayed inline by default
The three most commonly used values are none, block, and inline. All elements have an initial or default state for their display value.For all HTML5 elements, by default they have a computed display value of inline.
In HTML5, page and worker do not share the same instance
In HTML5, page and worker do not share the same instance – a duplicate is created on each pass. Data passed between the main page and workers are copied. Objects are serialized as they’re handed to the worker, and subsequently, deserialized on the other end. I read that most browsers implement this feature as structured cloning. (The structured clone algorithm is a new algorithm defined by the HTML5 specification for serializing complex JavaScript objects.) A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#webworkers
In HMTL5 Offline, relative URLs listed in a manifest are resolved relative to the manifest file
Yes, the urls in the manifest are relative to manifest’s own url. It is not to be confused that they are relative to root. Though it might happen that the urls relative to root work good because the manifest file might be located in the application root. A quick detail about the feature can be read here: http://www.codeproject.com/Articles/546960/HTML-Quick-Start-Web-Application#offlineapp CodeProject
I was learning HTML5 features since December. While going through it, I was playing around making a sample web application fully HTML5 enabled – kind of self learning kit that would give a basic knowledge to anyone who goes through it. Plan was to publish it as an article so that others can learn quickly and have basic features at one place. One can play around with the feature implementation straight away post download.
It took me some time to write the article as it covered good number of features. I finished working on it and have published it today on CodeProject: HTML5 Quick Start Web Application
One can have a look at it there and provide feedback.