Question

Now I am creating a chat application. I am currently using webapi to build the application backend. However I am thinking whether I should have used WCF for that. My aim is for the application to be a multi-tier application where the client could be any technology( not necessarily from microsoft stack). Is there any thing I should be worried in terms of extensibility point of view for the applications future.

Answer 1

If this was an ordinary Web API then I would say that WebApi used correctly would offer you the ability to use a very great range of client technologies – if they support interaction using HTTP; however, you are building a chat client which has some very different design considerations.

With a simple/vanilla WebApi interface to a chat client you will likely end up with an architecture that requires your clients to repeatedly poll for new messages – possibly not ideal. Most .NET chat examples you find will normally operate an the TCP level over sockets etc. e.g.these 3 examples and clients are able to ‘listen’ for messages, over Http things are not quite so simple.

There are WebApi examples that support push (or simulated push) that are well suited to chat API’s e.g. SignalR there are a good number of examples of using WebApi with SignalR to implement chat e.g. here and here – but how open SignalR is to other technology stacks may be an issue for you.

So to work at the TCP and Socket level with WCF may be best approach for you, but if you really do want a Web based Api to your solution and want push (type) messaging then look at SignalR or CometD for implementations, if you just want an open Web Api available to a number of client technologies without support for push then WebApi would be a perfectly good choice.

As an aside: To get the broadest range of support for clients e.g. existing chat clients etc consider using a standardised chat protocol like XMPP. This could be used over SignalR if required.