Materiales y vídeo hangout SignalR y Web API

El pasado viernes 14 de marzo estuvimos hablando, vía hangout, Juan Quijano y un servidor sobre SignalR y Web API. A nosotros se unieron también Jorge Serrano, Gorka Madariaga, Luis Fraile y David Salgado entre otros, y otros tantos que nos observaron a través de Youtube.

Continuar leyendo «Materiales y vídeo hangout SignalR y Web API»

My february pet project: RealPoll (10+ technologies + a lot of fun)

Test it live: Realpoll at Azure

After my fist side-project (which I might publish on march or april) with Angular.js, I’ve been playing with different web technologies by doing a remake of a hackathon idea: Meet realpoll.


The Idea

Teachers and speakers often need a way to engage the audience and give them the possibility to participate in the talk or the subject. Today is very common to see students tweeting from class, so this means they do have portable, wireless internet. The response of some centers is to block communications, but, why not use it the other way?

This web app allows the teachers to previously prepare some questions, choose the number of answers, the correct ones, and display the question on a projector. The students can then, use the url or capture the QR code generated from their cell phones. Once the question is generated, the trainer can choose the time that will be the poll open (in seconds).

When the time is up, the dashboard will mark the correct answers and those who answered correctly. The only data that is saved is the question and the answers, so you can come back and repeat it.

The voting interface is very, very simple: Just add a name and click on your chosen answer. It will be send inmediately to the dashboard.

Remake of a classic

The fact is that realpoll is a previous project done in a hackathon using a completely different tooling:

  • 100% HTML + Javascript
  • redis for the data layer
  • for handling the real time interaction
  • express.js for handling routing and views
  • google charts for the graphics
  • plain jquery for DOM management
  • Heroku as cloud host
  • developed with VIM

For this project, I wanted to keep the idea, but change completely the technologies used:

  • 50% HTML + Javascript, 50% C#
  • sql + entity framework for the data layer
  • signalr for the real-time interaction
  • MVC for handling routing and views
  • Chart.js for the graphics
  • jquery and Angular.js for handling the views
  • RazorEngine for the views
  • Git/github as SCM
  • Windows Azure as cloud host (connected to github)
  • Visual Studio + IE dev tools + Chrome dev tools (+ Safari dev tools on mac)
  • Sendgrid for mailing.



The backend is pure MVC with the data stored in a SQL Server database, and some services (such as email) for making my life a little bit easier.

The system uses the database for storing the questions, so we can access later from a single URL. The URL is a hash based on the question ID. The voting process is not stored, so it resets when we refresh the dashboard. The communication between the database and the app is done by using Entity Framework, Microsoft’s open source ORM.

For being able to use data without having to worry about the ORM, I used dependency injection techniques to inject a fake data source. The Depencency Injection framework chosen was ninject, and while I had to create two different classes for MVC and SignalR dependency solvers, I had a single entry point to replace the fake access with the ORM data source.



New question

The «New» page looks like this, It’s bootstrap for the UI and angular for handling the UI updates when the question number changes:



When we create a question, data is updated in the database and we see a confirmation page like this:


For generating the e-mail sent I use RazorParser, a nuget-available dll that allows me to generate an html view from a model and a file, and once generated use it as a string. The e-mail is sent through sendgrid’s SMTP, using the standard SMTP functions.

Result/dashboard Page

The result page is one of the most complicated, the charts are created by using chart.js with a wrapper for angular, the qr code is generated by using the qrickit API, and it’s updated in real time by using signalR and angular.js for handling the views.


When the time is up, the correct solution is highlighted, and those whose answer matches are highlighted also

Mobile Interface


As Bootstrap is mobile ready, I had to do few changes to make the ui work flawlessly, had to do some debugging on Safari for Mac (whose web developer tools are way less powerul than Chrome/IE’s) connected to an iPhone. The cookie consent also adapts so, no issues here.

Stats and cookies

As the goal of the project was to play with technology, I havne’t been playing troo much with stats, but I did have added a google analytics code in each page. Also as I’m on the EU, there is a strict control of which cookies can be installed in the user’s machine (even more strict in Spain) so I’ve used the cookie consent code that allows the user to control the analytics tracking.

Source control, deploy and debug.

The project has been done by using git as source control manager, github as repository and the deployment has been done in Windows Azure. Azure has a hook for git, so when I push to github it will deploy to azure. As is git-based, it allows me to rollback inmediately while keeping the continuous deployment options available.

Finally, for remote debugging I added Elmah (Error Logging Modules and Handlers) to track down exceptions and issues that happened in Azure.

Issues, curious and weird things

  • There is a bug with angular an Visual Studio’s browser link that causes constant debugger stops on frontend code, be aware.
  • For adding dependency injection with ninject for signalR and MVC, you need to define two different dependency solvers, because they belong to different assemblies and implement different interfaces.
  • Validating input data has become way easier with HTML5, butS afari (and specially safari for iPhone) do not support the required tag for html, a useful guide is caniuse
  • For debugging on Safari for iPhone you need Safari running on Mac OS X.
  • When you re-deploy a solution to azure, (with the configuration by default) you lose all the exceptions tracked by elmah
  • I’ve used some funny xml transformations for handling local, remote and fake databases.

Room for improvement

Of course, there are always things that may go better, I didn’t write a single line of test code (other than my fake db wrapper) so it should be considered fairly unstable. The goal of this mini-project was to integrate as many technologies as possible to create a ready-to-deploy real-time web application. I would have added some UI tests with selenium, and maybe some unit testing for both angular and mvc controller.

Try it!

You can test it live on Realpoll at Azure or you can get the source code from the project’s github repository and deploy it by yourself. You will need your own API keys and your own database for making it work. Comments will also be apreciated, and if you want to contribute back, just send a pull request!

SignalR with external assemblies and obfuscators

Developing with SignalR is a very interesting experience. The technology, which allows us to create solutions that interact in real time with the browser and native apps, provides us with several layers of abstraction over technologies such as WebSockets, so that we can focus on the specific features of our apps. However, sometimes these abstractions may be a problem more than a solution.

One of the cases we can see this is with the hubs. A hub is a class that, when processed by signalR, is exposed to the browser by using Javascript. Unlike a REST API, a hub does not (only) responds to a request, they can also send messages both to the client who has made the request, the rest of the clients connected, or all of them, in real time.

To define a hub, we only need a class that inherits from the Hub class and SignalR will do the rest. It will discover (by using reflection) all the different hubs in the current assembly and generate the corresponding javascript.

Here is an example with the following code in C#:

public class ChatHub : Hub
        public void Send(string name, string message)
            // Call the broadcastMessage method to update clients.
            Clients.All.broadcastMessage(name, message);

The generated code by SignalR looks a little bit like this:

 proxies.chatHub = this.createHubProxy('chatHub');
        proxies.chatHub.client = { };
        proxies.chatHub.server = {
            send: function (name, message) {
                return proxies.chatHub.invoke.apply(proxies.chatHub, $.merge(["Send"], $.makeArray(arguments)));

As I mentioned earlier, signalR hubs are discovered automatically for the current assembly. What hapens if we store our hubs on a different asembly, for example, if we have two apps who use the same hub? After searching, I found the solution on StackOverflow. As I only needed to load one specific assembly, I picked only this line:


This code loads the Assembly that contains the class so SignalR can «discover» the Hub, we must place it just before the app.MapSignalR() or otherwise the Hub will not be generated.


If we distribute our application our clients (for example when offering a solution containing SignalR so that they can install it on a local server) is usual to use tools like SmartAssembly or Dotfuscator, to protect the intellectual property of your code.

For a correct SignalR operation, it’s important to remember that we must not obfuscate, or prune the Hub classes, since the class is loaded by reflection. The obfuscation result will rename the classes and probably remove uncalled code (that is, in fact, called from Javascript). The best solution is to use hubs as a ‘proxy’ class and obfuscate those classes and methods called from the hub.

To avoid obfuscation you can can, either manually in the properties of the project, or through attributes. For SmartAssembly we find attributes such as [DoNotObfuscateType] and [DoNotPruneType] which apply to the whole class, and in the case of Dotfuscator we can use the [Obsufcation] attribute.

More information

Un tip rápido: SignalR, ensamblados externos y ofuscación

Desarrollar con SignalR es una experiencia muy interesante. La tecnología, que nos permite crear soluciones que interactúen en tiempo real con el navegador y con aplicaciones nativas, nos proporciona varias capas de abstracción sobre tecnologías como WebSockets, para que podamos centrarnos en el contenido de nuestras aplicaciones. Sin embargo, a veces los árboles no dejan ver el bosque.

Uno de los ejemplos se nos da con los hubs. Un hub es una clase que signalR expone al navegador mediante Javascript. A diferencia de una API REST, un hub no (solamente) responde a una petición, sino que puede enviar mensajes tanto al cliente que la ha realizado, a todos los clientes o al resto, en tiempo real, entre otras cosas.

Para definir un hub, solamente necesitamos una clase que herede de la clase Hub y SignalR hará el resto, es decir, descubrir los diferentes hubs y exponerlos al cliente.

Veamos un ejemplo, con el siguiente código en C#:

public class ChatHub : Hub
        public void Send(string name, string message)
            // Call the broadcastMessage method to update clients.
            Clients.All.broadcastMessage(name, message);

SignalR genera este código, que lo podemos ver acudiendo a la url http://miservicio/signalr/hubs:

 proxies.chatHub = this.createHubProxy('chatHub'); 
        proxies.chatHub.client = { };
        proxies.chatHub.server = {
            send: function (name, message) {
                return proxies.chatHub.invoke.apply(proxies.chatHub, $.merge(["Send"], $.makeArray(arguments)));

El hecho de que SignalR descubra de manera automática los hubs nos puede traer problemas cuando los hubs están en un ensamblado diferente al que está cargando SignalR (por ejemplo, si tenemos dos aplicaciones que usen exactamente el mismo tipo de hub).

Tras mucho buscar, la única solución que he encontrado para cargar los hubs desde otro ensamblado pasa por la siguiente línea:


Este código carga el ensamblado que contiene la clase para que SignalR «descubra» el Hub, y lo debemos situar justo antes de app.MapSignalR() o de lo contrario el Hub no se generará.


Si distribuimos nuestra aplicación a nuestros clientes (por ejemplo ofrecemos una solución que contiene SignalR para que la puedan instalar en un servidor local) es habitual recurrir a herramientas como SmartAssembly o Dotfuscator, para proteger la propiedad intelectual de nuestro código.

Para que el funcionamiento de SignalR sea correcto, es importante recordar que no debemos ofuscar las clases Hub, ya que la clase se carga mediante reflexión, y la ofuscación provoca o bien que la clase no sea encontrada con su nombre original, o bien que no se pueda acceder a los métodos, o bien que, al no ser llamados por otras partes de nuestro código, se deseche. La mejor solución pasa por usar los hubs como una clase «pantalla» y ofuscar aquellas que sean llamadas desde el hub.

Para evitar la ofuscación podemos, o bien de manera manual en las propiedades del proyecto, o a través de atributos. En el caso de SmartAssembly encontramos atributos como [DoNotObfuscateType] y [DoNotPruneType] que se aplican a toda la clase, y en el caso de Dotfuscator contamos con el atributo [Obsufcation]

Más información