Criando aplicativos em tempo real com o SignalR – Parte 1

O protocolo HTTP é a base para toda a comunicação pela web e atende às nossas necessidades desde os primeiros dias. O HTTP funciona em um modelo de solicitação e resposta, em que uma solicitação precisa ser enviada ao servidor para obter qualquer atualização de lá.

Isso cria desafios ao lidar com alguns cenários em que precisamos de dados em tempo real: quando um usuário abre uma página da web, ela precisa ser atualizada e quando há uma alteração no servidor, mas de acordo com a arquitetura HTTP, uma nova solicitação deve ser enviada para obter uma atualização do servidor. Isso cria uma experiência ruim para o usuário e várias solicitações também podem limitar a largura de banda da rede. Existem muitos cenários em tempo real em que precisamos mostrar dados ao vivo para o usuário (como informações do mercado de ações, resultados de jogos ao vivo, aplicativos de bate-papo e outros).

Para lidar com esses cenários, usamos diferentes soluções alternativas, nas quais o AJAX ajudou muito. O AJAX nos permite enviar uma solicitação (relativamente muito pequena) e atualizar a interface do usuário com base na resposta. Outros desafios que enfrentamos incluem o comportamento diferente dos navegadores em termos de recursos e suporte. Do ponto de vista do desempenho, a utilização de recursos e rede do servidor são outros problemas, portanto, não podemos enviar cegamente várias solicitações ao servidor. Da mesma forma, não podemos fazer o usuário esperar mais enquanto aguarda a atualização. É responsabilidade do desenvolvedor usar a melhor opção/protocolo disponível para lidar com a comunicação em tempo real.

O que é SignalR?

O SignalR é uma biblioteca de alto nível que facilita muito o desenvolvimento de aplicativos da Web em tempo real. Podemos escrever aplicativos da Web em tempo real usando AJAX, como discutido acima, ou podemos usar o Forever Frame ou algumas outras soluções alternativas personalizadas, mas elas são bastante complexas e uma lógica diferente é necessária para diferentes cenários. O SignalR oculta todas as complexidades envolvidas e funciona perfeitamente em todos os navegadores, incluindo diferentes versões. É muito poderoso e permite comunicações bidirecionais entre cliente e servidor. O servidor não é obrigado a aguardar a solicitação do cliente para enviar a resposta, em vez disso, ele pode enviar logicamente a resposta quando novos dados estiverem disponíveis. Ele lida com o próprio gerenciamento de conexão e nos permite transmitir/unicast mensagens para os clientes conectados.

Transport Mechanism

O SignalR usa uma das várias tecnologias para configurar comunicações entre o cliente e o servidor. O Web Socket, que foi introduzido com o HTML5, fornece suporte bidirecional, mas não é suportado por todos os navegadores e versões mais antigas. Como não podemos garantir qual navegador será usado pelo usuário, não podemos simplesmente confiar nisso, portanto, deve haver alguma maneira de implementar recursos semelhantes em todos os navegadores. Para fazer isso, o SignalR permite que você use várias tecnologias de transporte e selecione uma que seja mais adequada para o cenário.

Vamos discutir brevemente as tecnologias acima

Soquete da Web– Esta é uma nova tecnologia de comunicação que fornece uma verdadeira comunicação bidirecional em uma única conexão TCP na web. Em outras palavras, se ambas as partes (cliente e servidor) suportarem o soquete da web, isso criará uma conexão persistente entre elas que pode ser usada pelo cliente ou servidor para enviar os dados a qualquer momento. Como tal, isso é mais eficiente, consome menos memória e mostra a menor latência. Esse é o protocolo mais preferencial para um aplicativo SignalR.

Eventos enviados pelo servidor (também conhecido como fonte de eventos) – Esta é outra técnica introduzida com o HTML5 que permite que o servidor envie as atualizações para o cliente sempre que novos dados estiverem disponíveis. Essa tecnologia é usada quando o Web Socket não é suportado. É suportado pela maioria dos navegadores, exceto o IE.

Forever Frame– Faz parte do modelo COMET e usa um iframe oculto no navegador para receber os dados de maneira incremental do servidor. O servidor começa a enviar os dados em uma série de blocos, mesmo sem saber o comprimento total do conteúdo. Ele é executado no cliente quando os dados são recebidos.

Sondagem longa do AJAX– Essa é a maneira menos preferida no SignalR para configurar uma comunicação entre o Cliente e o Servidor. Além disso, é o mais caro de todos! Ele faz parte do modelo COMET e, como o nome sugere, continua pesquisando o servidor para verificar se há atualizações. A solicitação enviada ao servidor é baseada em AJAX, para minimizar o uso de recursos e fornecer uma melhor experiência do usuário. Mas ainda é caro porque continua pesquisando o servidor se há atualizações ou não.

Antes de prosseguir, vamos discutir os dois modelos diferentes usados para se conectar entre Cliente e Servidor: Conexão Persistente e Hub

Conexão persistente– Esta é uma API de nível inferior que nos permite enviar mensagens brutas para diferentes clientes. Também podemos personalizar isso com base nos diferentes tipos de mensagens e diferentes clientes, e também podemos enviar esses detalhes com a mensagem. Em palavras simples, por um lado, nos dá mais controle sobre a conexão e o envio de diferentes tipos de mensagens, enquanto, por outro lado, precisamos escrever mais código.

Hubs– São APIs de nível superior que são construídas sobre as conexões persistentes. Os hubs ocultam todas as complexidades do desenvolvedor e nos fornecem um modelo de estilo RPC simples com a função exclusiva definida.

Como usar o SignalR

O SignalR é bastante fácil de configurar e usar. Podemos apenas instalar o pacote nuget da seguinte maneira:

Ou podemos executar o seguinte comando por meio do Console do Gerenciador de Pacotes:

Install-Package Microsoft.AspNet.SignalR

Isso instala todos os componentes necessários do SignalR. Uma vez instalado, para começar a usá-lo, precisamos concluir as seguintes etapas:

1- Primeiro, precisamos configurar em nosso aplicativo. Para isso, precisamos criar uma classe chamada como Startup.cs e colocar o seguinte código lá:

    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            app.MapSignalR();
        }
    }

2- Crie uma classe Hub que deve herdar da classe Hub como:

public class MySignalRHub : Hub
{
    public void SendMessage(string message)
    {
        // Calls the call back function defined on client side
        Clients.All.SayHello("Hello !! Your Message : " + message);
    }
}

O Hub é o núcleo de qualquer aplicativo SignalR e é o Hub que facilita a comunicação entre cliente e servidor. Aqui, o método SayHello é um método JavaScript (veremos a seguir) que é chamado do Hub. O método SendMessage será chamado do cliente. O hub fornece a associação e a serialização do modelo prontas para uso.

3- Agora, no lado do cliente (digamos em Index.HTML), precisamos adicionar bibliotecas fluidas:

<script src="Scripts/jquery-1.6.4.min.js"></script>

<script src="Scripts/jquery.signalR-2.2.0.js"></script>

As bibliotecas acima são jQuery e SignalR necessárias para um cliente JavaScript. A versão mínima do jQuery é 1,6.4.

4- Agora, como o cliente se conecta ao método do servidor? Para isso, precisamos incluir o proxy Hub que é gerado dinamicamente. Usando isso, a comunicação acontece entre o servidor e o cliente. Está incluído como:

<script src="signalr/hubs"></script>

Observação – A ordem do arquivo no cliente deve ser a mesma que jQuery, jQuery SignalR e proxy de Hub.

5- Temos todos os recursos necessários no cliente. Agora precisamos escrever o código para chamar o código do lado do servidor e fornecer uma função de retorno de chamada que seria chamada do servidor quando o servidor recebesse qualquer atualização. Vamos ver isso no código:

var hubproxy = $.connection.mySignalRHub;

Esta é a instância de proxy que seria fundamental para a comunicação. Vamos definir o método de retorno de chamada como:

hubproxy.client.sayHello = function (message) {
    // Process your message
}

Agora, para chamar o método do lado do servidor como:

$.connection.hub.start().done(function () {
   $('#sendmessage').click(function () {
          // Call the Send method on the hub.
          hubproxy.server.sendMessage($('#tbmessage').val());                
   });
});

No código acima, há duas coisas principais. Primeiro, estamos iniciando o hub e, quando terminar, adicionaremos apenas o método click e chamaremos o sendMessage do hub. Isso não pode ser chamado antes de iniciar o hub.

As etapas acima são todas as necessárias para a configuração mínima de um aplicativo SignalR. Vejamos aqui a representação pictórica da comunicação entre cliente e servidor:

Nota – No lado do cliente, precisaremos chamar o método independentemente de como ele é escrito no servidor, caso contrário, ele não será chamado.

Conclusão

Nesta postagem, discutimos as complexidades de escrever aplicativos Web em tempo real e como o SignalR simplifica esse processo. Em seguida, discutimos os conceitos de modelos de conexão, modelos de transporte e como configurar a infraestrutura e começar a usar o SignalR. Fique ligado no meu próximo post, onde abordaremos os insights do SignalR com um exemplo da vida real.

Crie aplicativos Web modernos para qualquer cenário com suas estruturas favoritas.Baixar Ignite UIhoje e experimente o poder dos controles jQuery/HMTL5 Infragistics.