¿Es el rendimiento la única razón para no usar SignalR (websockets) completamente en lugar de una API REST tradicional?

38

He usado SignalR para lograr la funcionalidad de mensajería en tiempo real en varios de mis proyectos. Parece funcionar de manera confiable y es muy fácil de aprender a usar.

La tentación, al menos para mí, es abandonar el desarrollo de un servicio de API web y usar SignalR para todo.

Siento que esto podría lograrse mediante un diseño cuidadoso, y si lo fuera, significaría que se necesitaría mucho menos código de cliente. Lo que es más importante, significaría que habría una única interfaz para los servicios en lugar de una interfaz dividida, y en el peor de los casos, se podría conectar esto sin pensar en cuándo se renderizan las cosas, etc.

Por lo tanto, me gustaría saber:

  1. ¿Hay alguna otra razón para no usar SignalR en lugar de todos los servicios web además del rendimiento?
  2. ¿El rendimiento de SignalR es lo suficientemente preocupante en cuanto a que no tendría sentido hacerlo?

Durante mucho tiempo, mi sueño ha sido poder traducir las definiciones de objetos y servicios del lado del servidor al código de acceso al servicio del lado del cliente sin algo estúpido como node.js . Por ejemplo, si defino un objeto interesante InterestingObject y un servicio para CRUD el objeto InterestingObjectService , puedo definir una ruta URL estándar para el servicio, por ejemplo, "/ {serviceName} / {methodName}", pero Todavía necesito escribir el código del cliente para acceder al servicio. Dado que el objeto se pasará de cliente a servidor y volverá, no hay ninguna razón práctica para tener para definir el objeto explícitamente en el código del lado del cliente, ni debería ser necesario definir explícitamente el objeto. Rutas para realizar operaciones de CRUD. Siento que debería haber una manera de estandarizar todo esto para que sea posible escribir un cliente bajo el supuesto de que el acceso al servicio funciona desde el cliente al servidor y se realiza de forma tan transparente como si estuviera escribiendo un WinForms o Java Applet o aplicación nativa o lo que sea.

Si SignalR es lo suficientemente bueno para usar en lugar de un servicio web tradicional, puede ser una forma viable de lograrlo. SignalR ya incluye una funcionalidad para hacer que el concentrador funcione como el servicio que describo, así que podría definir un servicio de base común (CRUD) que ofrecería toda esta funcionalidad de manera inmediata con cierta reflexión. Luego casi podía dar por sentado el acceso al servicio, ahorrándome la molestia de volver a escribir el código para acceder a algo a lo que se podía acceder por convención, y lo que es más importante, el tiempo que tendría que dedicar a escribir código para definir cómo se actualiza esto en el DOM.

Después de leer mi edición, siento que puede ser un poco absurdo, así que no dude en preguntarme si tiene alguna pregunta sobre lo que estoy diciendo. Básicamente, quiero que el acceso al servicio sea lo más transparente posible.

    
pregunta tacos_tacos_tacos 07.11.2014 - 11:39

2 respuestas

47

Esas dos tecnologías tienen un propósito muy diferente.

  • REST es para llamadas normales a una API, siendo el cliente un actor activo del intercambio. Cuando el cliente necesita encontrar las coordenadas GPS de una dirección, el cliente inicia la llamada a la API y espera hasta que reciba las coordenadas, o se produce un error, o transcurre un tiempo de espera.

  • Los sockets web son para todo lo que necesita hacer las cosas de manera opuesta. Por ejemplo, cuando uso un sitio web de intranet que me muestra en tiempo real los registros y el rendimiento de diferentes servidores, el cliente puede ser pasivo y esperar hasta que el servidor le envíe un mensaje de registro o rendimiento recientemente publicado. métricas.

La diferencia es clara: en el primer caso, el cliente decide cuándo necesita una información específica; en el segundo caso, el cliente simplemente espera ser contactado, y puede que no sepa cuándo sería.

De alguna manera, ambos son intercambiables: puede implementar sockets web cuando no los necesite (es decir, el cliente llamará al servidor a través de sockets web en lugar de hacer una llamada REST) y puede usar sondeo o sondeo largo como un sustituto a los sockets web (dado que se usó con éxito durante años hasta que los sockets web se hicieron tan populares).

Pero su intercambiabilidad tiene un costo:

  • Cuando usas sondeo o sondeo largo en lugar de sockets web, a menudo estás desperdiciando ancho de banda.

  • Cuando usa sockets web para hacer lo que se puede hacer a través de la API web, mantiene abiertas todas las conexiones de todos los clientes activos, lo que puede que no sea lo que realmente desea. Para un sitio web pequeño donde espera tener como máximo 5 clientes al mismo tiempo, esto no es un problema. Para un servicio como Amazon AWS, esto no sería fácil de resolver técnicamente.

No uses sockets web cuando no los necesites. Para obtener las coordenadas GPS de una dirección, no obtengo nada al abrir la conexión de sockets web, hacer la llamada, esperar una respuesta y cerrar la conexión: REST satisface mis necesidades para tales escenarios.

  • Si se encuentra comprobando repetidamente y con frecuencia la información a través de una llamada REST a un servicio, esto puede ser una buena señal de que debe pasar a los sockets web. De manera similar, Stack Overflow reduce el uso de ancho de banda al usar sockets web, ya que ayuda a las personas a no gastar su tiempo presionando F5 en la página de inicio para ver si tienen nuevos mensajes.

  • Si descubre que abre conexiones de sockets web, úselas para hacer una sola llamada y luego ciérrelas, o si sus conexiones permanecen abiertas pero el servidor envía algo al cliente solo a petición del cliente, cambie REST.

Además, los sockets web aún tienen un soporte limitado y no siempre son fáciles de implementar. Si bien SignalR facilita la implementación, esto no significa que no tendrá dificultades para implementarlo en otros idiomas / contextos / entornos. Con REST, eso es fácil: puede ser una llamada curl o una función similar disponible en todos los idiomas principales. Con los sockets web, no puede estar seguro de cuánto tiempo le tomará a un cliente usar [ingrese el nombre de un idioma que aún no conozca aquí].

He usado sockets web en varios proyectos en .NET, Python y node.js.

  • En .NET, no fue demasiado difícil, pero aún así, todavía pasé unos días tratando de resolver algunos problemas crípticos, como la conexión que se interrumpió tan pronto como se abrió. (Esto fue antes de SignalR; nunca probé SignalR). También utilicé WCF en modo web sockets, que tampoco estuvo exento de problemas (pero creo que WCF siempre viene con problemas).

  • En node.js, esto era factible, pero tuve que cambiar dos veces las bibliotecas hasta que encontré una que funciona. Creo que he pasado al menos una semana tratando de hacer un sockets web Hello World.

  • En Python, lo intenté una vez, pasé dos o tres días y lo abandoné. Nunca funcionó.

Compare esto con REST: el único problema que se puede encontrar con un nuevo lenguaje / marco es saber cómo enviar archivos POST o recibir una respuesta binaria muy grande. Recuerdo que pasé unas horas buscando soluciones para algunos idiomas. Sin embargo, unas pocas horas para un caso especial no son nada en comparación con días o semanas para un simple Hola Mundo.

    
respondido por el Arseni Mourzenko 07.11.2014 - 16:21
1

Solo mis 2 centavos ...

Creo que no se trata realmente de rendimiento o de cualquier tipo. Se trata de estándares. REST es un estándar e IMHO tiene las siguientes ventajas:

  • Las solicitudes HTTP son fáciles de usar. Todo el mundo puede usar rápidamente una API REST. Diablos, incluso puede abrir el navegador y escribir una URL para ver los datos, ¿qué tan interactivo puede ser?
  • (Casi) cualquier lenguaje de programación puede usarlo. Es una especie de interfaz universal. La interfaz con SignalR desde un lenguaje exótico parece menos obvia.
  • Tiene un buen soporte de herramientas, como enlace
  • Es una buena "interfaz" para depurar. Puede monitorear fácilmente los mensajes entrantes y salientes directamente en el navegador, ver los datos, etc. Con websockets y bibliotecas personalizadas, no es tan obvio, tiene que registrar todo explícitamente.
respondido por el dagnelies 07.11.2014 - 15:31

Lea otras preguntas en las etiquetas

Comentarios Recientes

Datos, sistemas de render, personalizados: todos son modelos de juego diferentes por derecho propio, con diferentes restricciones que dependen de lo que intente lograr, así como de su realidad y preocupaciones pragmáticas. No existe un protocolo web realmente obvio para los dispositivos informáticos avanzados. Desde el punto de vista del desarrollador de pantallas decodificadoras, este tipo de API HTTP general es equivalente a la forma en que los desarrolladores web usan WebSockets en los navegadores (Sockets HTTP... Lee mas