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:
- ¿Hay alguna otra razón para no usar SignalR en lugar de todos los servicios web además del rendimiento?
- ¿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.