6

I'm trying to create a new application from the ground up. I've used SignalR and WebAPI. I believe I know a lot of the differences, but isn't SignalR faster since it uses websockets? WebAPI makes sense to me for external frameworks to be able to reuse. SignalR makes sense to me for anything I'm not necessarily going to use externally. I've done some research and I can't find anywhere it says you shouldn't. I realize this is somewhat opinion-based, but why would you use a mix of the two rather than just SignalR?

I think what I'm mostly asking is if it is wrong to use SignalR to send back to the caller, except in cases where I would send to other clients on that channel? To me SignalR can be used like WebAPI when you are just sending back to the client. Is that wrong to do? It is less code for the client calls(2 lines vs 6 or more, depending on what I'm doing with it). My thinking is I may be trying to manipulate data and send it to the caller now, but maybe I want to send it to all clients later or send a notification to all clients. I'm not a fan of using signalR calls in my webApi controllers. It just feels like the signalR calls should be in the Hub. Thanks for your help.

Taylor Mitchell
  • 614
  • 11
  • 27

2 Answers2

10

There is no reason why you shouldn't use them together because they target two different problems. Web-API is a means of making web services easy to target by many different kind of apps/devices whereas SignalR offers bi-directional communications in a way that the Server can call a piece of code on the client without the client having to keep polling the server for results.

E.g. Instead of having a client keep asking the Server for any new messages (like facebook notifications) with SignalR the server knows that there are new notifications for a specific client and it can send them directly without the client having to ask for them.

http://www.asp.net/web-api

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

http://www.asp.net/signalr

ASP.NET SignalR is a new library for ASP.NET developers that makes developing real-time web functionality easy. SignalR allows bi-directional communication between server and client. Servers can now push content to connected clients instantly as it becomes available. SignalR supports Web Sockets, and falls back to other compatible techniques for older browsers. SignalR includes APIs for connection management (for instance, connect and disconnect events), grouping connections, and authorization.

A potential problem is that while SignalR is great at targeting JavaScript code on a client, Web-Api enables connectivity with all sorts of platforms and devices. So the same techniques used through SignalR to target Web Browsers, will not necessarily work on a native Android App.

Ted
  • 3,985
  • 1
  • 20
  • 33
  • That makes sense. My OCD wants to use only one technology because the code looks cleaner. When you first learn SignalR most tutorials want you to connect to the hub and then call a hub method, which really makes you ask, wait...isn't that what WebAPI does here? It's almost essentially the same, you call the server and get data back, however for something that would be more of a post method, you might want to let other clients know that a model has been created. Anyways, it makes sense to use both, I just wanted clean and correct code. – Taylor Mitchell Sep 28 '16 at 11:00
  • @TaylorMitchell - As I wrote in my answer, `SignalR` is bi-directional.That means that the **Server** can call a `JavaScript` function on a **Client** in addition to normal **Client-Server** communication. You cannot do that in `Web-API` alone – Ted Sep 28 '16 at 11:04
  • That's the way I understand it. – Taylor Mitchell Sep 28 '16 at 11:31
6

You can use them together depending on your application needs. I recommend you look at difference between HTTP and WebSockets protocols. WebApi uses HTTP(S), SignalR mostly WebSockets and in some cases others transports. They both have benefits and disadvantages. The main benefits of using SignalR are duplex bidirectional communication as mentioned above and low traffic overheads. Browsers send as a rule a few KB data in HTTP headers and cookies for every request.

It’s easier to use RESTfull services (HTTP) from browsers, HTTP clients, tools, languages and so on instead of using WebSockets. Google Chrome supports monitoring WebSockets traffic but very poorly and Microsoft Edge doesn’t.

Many tools like Google Analytics and Microsoft Azure Application Insights can monitor errors in HTTP requests but can’t do this for WebSockets. You need to implement monitoring manually. Actually WebSockets traffic is simple messages from client to server and vise versa, no additional information. SignalR has some wrappers for this - some kind of error message format.

WebSockets also use more server resources because of keeping open TCP connection and it’s harder to scale web applications that use WebSockets. For instance if you have 100K online users it means you have to be able to keep 100K TCP connections. For HTTP – not necessary. For some very simple sceneries you can replace SignalR with some kind of client polling, but be careful that’s approach may bring a lot of problems.

So, If you don’t need bidirectional communication and traffic overhead (as a rule a few KB per request) is not a big deal then use WebApi only.

If you need bidirectional communication you can use SignalR for server to client push notifications and WebApi for client to server requests simply to ease development, scaling, debugging and using API from other sources. But you also can use SignalR only if you are ok with disadvantages of it or traffic overhead is big for you.

Vasyl Zvarydchuk
  • 3,789
  • 26
  • 37