Artigo no estilo: Curso

De que se trata o artigo

O artigo trata de como criar um mural de rede social utilizando técnicas de composição de HTML no browser do cliente utilizando o padrão MVVM. Além disso, usa a biblioteca SignalR.Net para a comunicação em tempo real multiusuário com ASP.NET MVC, C# e JavaScript.

Em que situação o tema é útil

É útil em aplicações web com uma ou mais características de rede social (como notificações, atualizações, bate-papo, mural e fórum), que demandam comunicação em tempo real e atualização intensiva da interface HTML.

Como Criar Um Mural de Rede Social

Neste primeiro artigo iremos apresentar algumas bibliotecas, técnicas, ferramentas e uma aplicação web totalmente funcional que imita algumas das funcionalidades do Facebook.

Vamos utilizar o framework Fluent NHibernate para implementar o mapeamento do modelo de dados, de forma limpa e sem configurações via XML. Em seguida, criaremos cuidadosamente as views aplicando client-side composition e MVVM binding com a ajuda da biblioteca Knockout, e para deixar a aplicação com jeito de rede social vamos utilizar a biblioteca SignalR.Net para fazer todo o trabalho de “encanamento” para nossas comunicações em tempo real.

Por muitos anos, ficamos presos a um modelo onde o navegador e a web apenas eventualmente se conectam e trocam informações: isso tem muito a ver com o fato de o HTTP ser um protocolo stateless, isto é, um protocolo sem estado. Em outras palavras o HTTP interpreta a comunicação de uma aplicação web como uma sequência de pares independentes de requisições e respostas. Para o HTTP, cada nova requisição não é tratada como uma continuação da requisição anterior, mas sim como uma nova requisição. Para resolver esse problema, ao longo dos anos foram criados mecanismos de autenticação e preservação do estado da navegação, como os cookies, as sessões e os ViewStates, que passaram a ser enviados ao servidor a cada requisição, para ajudar a identificar o autor dos chamados, a sessão e o estado da página. Nesse estágio da web, toda requisição feita ao servidor era uma requisição de página completa, mesmo que a alteração fosse apenas um elemento. Tomando como exemplo um gerenciador de e-mail online, a página de caixa de entrada teria que ser totalmente recarregada para que fosse atualizada uma única linha indicando que um e-mail acabou de chegar. Com a popularização de sistemas que funcionam inteiramente na Web e também com o aumento da velocidade das conexões banda larga, o problema da espera pelo envio e retorno da página inteira se tornou muito mais evidente para o usuário.

Depois foram amadurecendo os componentes que permitiram utilizar o potencial da tecnologia AJAX, entre elas a API chamada XMLHTTPRequest, escrita em JavaScript. Cada requisição XMLHTTPRequest partia do código JavaScript e o resultado era devolvido para esse mesmo código, e então algum elemento da página era atualizado, como por exemplo, a linha contendo o e-mail novo. Com requisições mais leves, respostas com menor consumo de rede e atualização mais rápida do conteúdo das páginas, em pouco tempo os principais websites passaram a utilizar Ajax em larga escala e logo ele se tornou padrão da indústria. As principais vantagens das aplicações AJAX é que os dados enviados e recuperados pela rede são reduzidos e o usuário não precisa esperar a página ser recarregada a cada resposta do servidor. Apesar de não possuir nada inovador em sua essência, o uso de AJAX revolucionou o desenvolvimento web. Havia claramente uma necessidade de se criar uma web mais ágil e interativa, mais eficiente no consumo de dados, e com melhora significativa na comunicação entre o navegador e o servidor. Nesse ponto em particular havia o problema bastante comum em que a página no navegador não tomava conhecimento sobre atualizações importantes que ocorriam no servidor. Para isso surgiram técnicas como o pooling, onde o código JavaScript do navegador envia requisições Ajax ao servidor em intervalos de tempo regulares, para obter possíveis notificações e atualizar a página adequadamente. Embora o pooling resolvesse o problema das notificações, ele não era uma solução de tempo real, pois as atualizações não eram instantâneas e, além disso, havia o problema sério de consumo de recursos de processamento excessivos tanto do navegador quanto do servidor. Este, particularmente, sofria com o número de requisições que cresciam em progressão geométrica devido à entrada de novos usuários realizando pooling ao mesmo tempo, o que prejudicava muito e até comprometia a escalabilidade da aplicação.

Para resolver isso, tempos depois surgiram especificações HTML5 descrevendo os WebSockets, como uma tecnologia que fornece canais full-duplex de comunicação bidirecional sobre uma conexão TCP, projetada inicialmente para (mas não limitada a) navegadores e servidores web. Os WebSockets resolvem definitivamente o problema da falta de um mecanismo eficiente de conexão persistente e notificação entre cliente e servidor, porém, a tarefa de configurar um servidor para fazer uso de WebSockets pode se tornar inviável para quem trabalha com tecnologias Microsoft, já que os WebSockets são suportados somente a partir do Windows 8, Windows Server 2012 e Internet Explorer 10. Para arquitetos, analistas e desenvolvedores, isso restringe muito a configuração mínima necessária dos servidores e dos usuários para que a tecnologia WebSockets funcione.

Por esse motivo, foi criada a biblioteca SignalR.Net, que fornece toda a infraestrutura para o uso de uma conexão persistente entre o navegador e o servidor web de maneira simples de se configurar e transparente para o desenvolvedor, permitindo trabalhar com todos os servidores ASP.NET e navegadores existentes no mercado. Internamente, o SignalR.Net pode trabalhar com WebSockets , caso eles existam na infraestrutura do servidor. Caso os WebSockets não estejam presentes, o SignalR.Net irá utilizar a estratégia de long pooling. que é um mecanismo em que o código JavaScript de cada navegador estabelece uma conexão persistente com o servidor web (isto é, a conexão nunca expira) até que o servidor envie uma mensagem para o navegador. Quando a mensagem é retornada, a conexão é interrompida e então o SignalR.Net automaticamente reestabelece uma nova conexão persistente entre aquele navegador e o servidor web. Isso emula a conexão real em duas vias fornecidas nativamente pelos WebSockets. Tudo isso de forma transparente, sem que o desenvolvedor precise conhecer os detalhes desse mecanismo.

Podemos dizer que o SignalR.Net possibilita e simplifica o desenvolvimento de aplicações que fazem parte do que poderíamos chamar de “nova web”: mais dinâmica, ágil, interativa e (porque não dizer?) muito mais “social”. Sim, é importante frisar que o aspecto “social” das aplicações web não pode mais ser deixado de lado. E com “social” não queremos dizer que o usuário simplesmente tenha acesso a “joguinhos” (apesar da crescente indústria que há por trás desse negócio), mas sim explorar o lado do comportamento humano em que as pessoas buscam a comunicação com outras pessoas. Muito mais do que estabelecer conexões, a nova web permite que as pessoas se expressem, digam o que pensam, sejam ouvidas e também sejam ouvintes de outras pessoas. São novos canais de comunicação que se abrem e que agregam valor ao produto. Colocar pessoas em primeiro plano é algo que muitas aplicações web modernas almejam, pois a participação coletiva é um termômetro importante, que mede o grau de interesse e de satisfação dos usuários com relação ao produto, e que quando necessário também permite a tomada de ações rápidas com relação ao comportamento desses usuários.

Não é à toa que o aspecto “social” é o fator de sucesso de muitas ideias que rapidamente se tornaram negócios bilionários nos últimos anos: Basta olhar os exemplos do GMail, Facebook, Google Plus, Outlook.com e Twitter, que conectam usuários numa escala gigantesca e gerenciam milhões de conexões simultâneas. Veja também o que ocorre com os “jogos sociais” como FarmVille, CityVille e The Sims Social. Todos eles se baseiam num mecanismo que conecta múltiplos jogadores de diversas partes do mundo através de serviços de um mesmo hub, ou “centro”, no qual os usuários se autenticam para ter acesso aos aplicativos sociais. E quanto mais usuários engajados, maior o número potencial de novos consumidores e de novas transações realizadas como pagamento de serviços que são oferecidos pelas aplicações “sociais”.

Com certeza o Facebook é o exemplo mais evidente dessa era “social” da tecnologia em que vivemos. Ele começou como um serviço exclusivo para alunos das universidades americanas mais prestigiadas e foi se espalhando rapidamente até chegar a praticamente todas as pessoas do mundo com acesso a um computador ou um telefone celular. Com o astronômico número que beira 1 bilhão de pessoas cadastradas, o Facebook não chegou ao topo por acaso. Mesmo não sendo a primeira rede social, em pouco tempo se tornou líder do mercado e obrigou as concorrentes a buscar nichos onde pudessem sobreviver.

Do ponto de vista de usabilidade e experiência do usuário, o Facebook também teve uma vantagem clara: o “Mural” e o “Feed de Notícias”, que são duas características muito importantes do website, que podem ser vistos como o “ponto de encontro” dos usuários. Talvez eles sejam a experiência mais exemplar da rede social. Por ali cada pessoa vê ideias, música e tudo aquilo que é considerado interessante pelos seus amigos. E também é convidada a se engajar em discussões, curtir e compartilhar postagens e se atualizar com os tópicos do momento.

O Mural é um espaço na página de perfil do usuário que permite aos amigos enviar postagens para que o usuário veja. Ele é visível para qualquer pessoa com permissão para ver o perfil completo, e posts diferentes no mural aparecem separados no "Feed de Notícias". Muitos usuários usam os murais de seus amigos para deixar recados temporários. Mensagens privadas são salvas em "Mensagens", que são enviadas à caixa de entrada do usuário e são visíveis apenas ao remetente e ao destinatário.

...
Quer ler esse conteúdo completo? Tenha acesso completo