O desempenho é o único motivo para não usar o SignalR (websockets) inteiramente no lugar de uma API REST tradicional?

39

Eu usei SignalR para alcançar a funcionalidade de mensagens em tempo real em vários dos meus projetos. Parece funcionar de forma confiável e é muito fácil de aprender a usar.

A tentação, pelo menos para mim, é abandonar o desenvolvimento de um serviço de API da Web e usar SignalR para tudo.

Eu sinto que isso poderia ser alcançado por um design inteligente e, se fosse, significaria que seria necessário muito menos código do cliente. Mais importante, isso significaria que haveria uma única interface para os serviços, em vez de uma interface dividida, e, no pior dos casos, poderia-se conectar sem pensar em quando as coisas são renderizadas, etc.

Então, eu gostaria de saber:

  1. Existe algum outro motivo para não usar o SignalR em vez de todos os serviços da web além do desempenho?
  2. O desempenho da SignalR é suficientemente preocupante para que não faça sentido fazê-lo?

Há muito tempo, é um sonho meu poder traduzir as definições de objeto e serviço do lado do servidor para o código de acesso de serviço do lado do cliente sem algo tolo como node.js . Por exemplo, se eu definir um objeto interessante InterestingObject e um serviço para CRUD o objeto InterestingObjectService , posso definir uma rota de URL padrão para o serviço - digamos, "/ {serviceName} / {methodName}" - mas Eu ainda preciso escrever o código do cliente para acessar o serviço. Como o objeto vai ser passado do cliente para o servidor e vice-versa, não há razão prática para ter definir o objeto explicitamente no código do lado do cliente, nem deve haver a necessidade de definir explicitamente o código rotas para executar operações CRUD. Eu sinto que deveria haver uma maneira de padronizar tudo isso para que seja possível escrever um cliente sob a suposição de que o acesso ao serviço funciona do cliente para o servidor e de volta de forma tão transparente quanto se eu estivesse escrevendo um WinForms ou Java Applet ou Native App ou o que você tem.

Se o SignalR for bom o suficiente para usar no lugar de um serviço da Web tradicional, pode ser uma maneira viável de conseguir isso. O SignalR já inclui funcionalidades para fazer o hub funcionar como um serviço que eu descrevo, então eu poderia definir um serviço de base comum (CRUD) que ofereceria toda essa funcionalidade pronta para uso com alguma reflexão. Então, eu poderia quase dar como certo o acesso ao serviço, poupando-me o incômodo de reescrever o código para acessar algo que poderia ser acessado por convenção - e, mais importante, o tempo que eu gastaria escrevendo código para definir como isso é atualizado o DOM.

Depois de ler a minha edição, sinto que pode ser um pouco absurdo, por isso sinta-se à vontade para perguntar-me se tem dúvidas sobre o que estou a fazer. Basicamente, quero que o acesso ao serviço seja o mais transparente possível.

    
por tacos_tacos_tacos 07.11.2014 / 11:39
fonte

2 respostas

48

Essas duas tecnologias têm um propósito muito diferente.

  • REST é para chamadas comuns para uma API, com o cliente sendo um ator ativo da troca. Quando o cliente precisa encontrar coordenadas de GPS de um endereço, o cliente inicia a chamada para a API e aguarda até receber as coordenadas, ou ocorre um erro ou um tempo limite.

  • Os sockets da Web são para tudo que precisa fazer as coisas do jeito oposto. Por exemplo, quando eu uso um site de intranet que mostra em tempo real os logs e o desempenho de servidores diferentes, o cliente pode ser passivo e esperar até que o servidor envie a ele uma mensagem de log ou desempenho recém-publicado métricas.

A diferença é clara: no primeiro caso, o cliente decide quando precisa de uma informação específica; no segundo caso, o cliente simplesmente espera ser contatado e pode não saber quando será.

De alguma forma, ambos são intercambiáveis: você pode implementar soquetes da web quando não precisar deles (ou seja, o cliente chamará o servidor por meio de sockets da web em vez de fazer uma chamada REST) e poderá usar sondagem ou sondagem longa como um substituto para web sockets (dado que isso foi usado com sucesso por anos até que os sockets web se tornaram tão populares).

Mas a sua permutabilidade tem um custo:

  • Quando você usa polling ou long polling ao invés de web sockets, muitas vezes você está perdendo banda.

  • Quando você usa web sockets para fazer o que pode ser feito através da API da web, você mantém todas as conexões de todos os clientes ativos abertos, o que pode não ser o que você realmente deseja. Para um site pequeno onde você espera ter no máximo 5 clientes ao mesmo tempo, isso não é um problema. Para um serviço como o Amazon AWS, isso não seria fácil de resolver tecnicamente.

Não use sockets da Web quando não precisar deles. Para obter coordenadas de GPS de um endereço, não ganho nada ao abrir a conexão de soquetes da Web, fazer a chamada, esperar por uma resposta e fechar a conexão: o REST atende às minhas necessidades para esses cenários.

  • Se você se encontrar repetidamente e freqüentemente verificando informações por meio de uma chamada REST para um serviço, isso pode ser um bom sinal de que você deve migrar para os sockets da web. Da mesma forma, o Stack Overflow reduz o uso de largura de banda usando sockets da Web, pois ajuda as pessoas a não gastarem seu tempo pressionando a tecla F5 na home page para ver se há novas mensagens.

  • Se você achar que você abre conexões de soquetes da Web, use-as para fazer uma única chamada e, em seguida, fechá-las ou se suas conexões permanecerem abertas, mas o servidor estiver enviando algo ao cliente apenas na solicitação do cliente, alterne para REST.

Além disso, os sockets Web ainda têm um suporte limitado e nem sempre são fáceis de implementar. Embora o SignalR facilite a implementação, isso não significa que você não terá dificuldades em implementá-lo em outros idiomas / contextos / ambientes. Com o REST, isso é fácil: pode ser uma chamada curl ou um recurso semelhante disponível em todos os idiomas principais. Com web sockets, você não pode ter certeza de quanto tempo levaria para fazer um cliente usando [insira o nome de um idioma que você ainda não conhece aqui].

Eu usei sockets web em vários projetos em .NET, Python e node.js.

  • No .NET, não foi muito difícil, mas ainda assim, passei alguns dias tentando descobrir alguns problemas misteriosos, como a conexão que caiu assim que é aberta. (Isso foi antes da SignalR; eu nunca tentei SignalR). Eu também usei o WCF no modo sockets da web, o que não foi isento de problemas (mas acredito que o WCF sempre vem com problemas).

  • Em node.js, isso era factível, mas eu tive que trocar duas vezes as bibliotecas até encontrar uma que funcionasse. Acredito que passei pelo menos uma semana tentando fazer um web sockets Hello World.

  • No Python, tentei uma vez, passei dois ou três dias e abandonei. Nunca funcionou.

Compare isso com o REST: os únicos problemas que um usuário pode encontrar com um novo idioma / framework é saber como enviar arquivos POST ou receber uma resposta binária muito grande. Lembro-me de passar algumas horas procurando soluções para alguns idiomas. Ainda assim, algumas horas para um caso especial não é nada comparado a dias ou semanas para um simples Hello World.

    
por 07.11.2014 / 16:21
fonte
1

Apenas meus 2 centavos ...

Eu acho que não é realmente sobre performance ou qualquer coisa. É sobre padrões. REST é um padrão e IMHO tem as seguintes vantagens:

  • As solicitações HTTP são fáceis de usar. Todos podem usar rapidamente uma API REST. Poxa, você pode até abrir o navegador e digitar uma URL para ver os dados, o quanto mais interativo você pode ser?
  • (Quase) qualquer linguagem de programação pode usá-lo. É uma espécie de interface universal. A interface com o SignalR de uma língua exótica parece menos óbvia.
  • Ele tem um bom suporte de ferramentas, como o link
  • É uma boa "interface" para depurar. Você pode facilmente monitorar mensagens de entrada e saída diretamente no navegador, ver os dados, etc. Com websockets e bibliotecas personalizadas, não é tão óbvio, você precisa registrar tudo explicitamente.
por 07.11.2014 / 15:31
fonte