Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Parent Full thread

I love C# and .NET, but WCF is a true source of frustration. It isn't horribly bad, but there is nothing good about it either. It's too complex, too messy, and too "Microsofty" for lack of a better word. Many layers of abstraction, hidden magic in XML files (which you can of course turn off, but then you need to know how to), and so on. Nevertheless, shares of coders blindly use WCF, "because Microsoft tells us to". Bullshit, and what a waste.

There are very few modern use cases where WCF is the best option out there. If you want to make a RESTful API with .NET, please consider:

     * ASP.NET MVC Web API
     * ServiceStack
     * Nancy

Nancy is basically Ruby's Sinatra but then on .NET.

ServiceStack recently became commercial, but it still is the best designed API library I've ever seen, in any language. It makes you focus more on the actual data inside each request and response, and less on the form of that data (is it a query parameter, JSON POST field, or part of a fancy URL? who cares, design your messages first and then figure out what the URLs should look like). The result of this is that somehow you tend to automatically design forward-compatible, extensible API endpoints. I guess you really have to feel it to believe it, but I kid you not, with ServiceStack, it feels like your API designs itself in front of your eyes.

If anyone knows anything like ServiceStack on any other language, please tell me and I'm going to give you hugs.

Finally, MVC Web API is basically Rails's API controllers ported to C#. It has a tad too much magic for my taste, but it's a familiar and decent pattern that just works.

Please, please, let's just bury WCF and embrace the true goodies in the .NET open source ecosystem. It's nice that WCF got open sourced, but it's still a mess. If you really must go the "because Microsoft!" route, please just use ASP.NET MVC (also open source, and in active development).

It's worth remembering that the technologies you mentioned weren't around when WCF was created.

As far as I can tell, Microsoft doesn't really push WCF any more simply because the use-cases are fewer and/or irrelevant in the current Web Service landscape.

I also get the feeling that many people commenting here didn't need to work with WS-* and associated technologies at the time WCF didn't exist. After its release it really was a choice between the lesser of two evils. But at the time, WCF was the mischievous kid who didn't do his homework, and everything else was the direct spawn of Satan.

A reminder of what WCF is (Wikipedia):

> a runtime and a set of APIs in the .NET Framework for building connected, service-oriented applications

> WCF is a tool often used to implement and deploy a service-oriented architecture (SOA)

For people who were around during the SOA dark ages, I won't be surprised if reading that sent shivers down your spine. Thankfully SOA, as it was evangelized, is pretty much dead. For everything else, these days better data-interchange technologies exist.

Wasn't there web services before WCF to deal with SOAP? And I seem to remember they were easier to use than WCF. I also go the feeling that when WCF was released it killed off quite a bit of the evolving open source stuff.

Could be wrong, but you seem to be downplaying how much of a development drag WCF ended up being on .Net and how poorly it is designed.

I was around that time too, and for me WCF was like a blast from the past even back then. It was like a bad .Net 1.0 library when it was brought out. Almost everything they could design badly and enterprisey, they managed to design badly and enterprisey. It reminded me of that terrible enterprise library they had.

Still pretty useful in consuming Salesforce's terrible api though.

> Wasn't there web services before WCF to deal with SOAP?

Yes, you used Web Services to deal with SOAP messages. But SOAP was never the problem. WS-* was.

> These variety of specifications are the basic web services framework established by first-generation standards represented by WSDL, SOAP, and UDDI.[1] Specifications may complement, overlap, and compete with each other. Web service specifications are occasionally referred to collectively as "WS-", though there is not a single managed set of specifications that this consistently refers to, nor a recognized owning body across them all.

http://en.wikipedia.org/wiki/List_of_web_service_specificati...

I also don't understand why people think that "enterprisey" is inherently a bad thing? It was designed to be used in the enterprise. This is evident in it's relationship to SOA, which is basically its raison d'etre. When you build apps in enterprise environments you have to put with all kinds of crap to appease auditors and to adhere to various acts and governance frameworks and protocols so that you can maintain your position on whatever Stock Exchange etc. That's just the nature of the beast.

Enterprisey doesn't mean designed to work in an enterprise. It never has.

It's a pejorative term, not a descriptive one.

It means an over engineered solution to a simple problem that suffers heavily from YAGNI. It means catering to the 0.1% scenarios over the 99.9% scenarios. It means a complex generic solution where a simple one would have been better with custom code being used to handle the occasional complex scenario.

> It means an over engineered solution to a simple problem

This is exactly my point. SOA in practice is not a simple problem, and it's the reason WCF exists so of course it's going to be complex. The whole idea of SOA means that you're inherently stuck with the problem of communicating with different different systems that talk different languages, by trying to coerce them into communicating via a standard format, which for all intents and purposes was rarely "standard". And of course these things have to be done in a secure fashion, with logging and auditing every step of the way, and with the ability to change configuration properties by editing a text file instead of having to via a Change Control Board and the entire QA process.

My feeling is that people who were using WCF for "simple" problems were probably using the wrong tool, even though in most cases it would have probably worked fine.

SOA in practice is not about the communication framework, it's about the delivery culture and discipline of using published interfaces of any sort in the first place. Amazon is perhaps the most successful example of a CEO-mandated SOA, they didn't really need something like WCF. Netflix used RESTful HTTP mostly for theirs.

Of course everything else you say about logging, changing, etc. is correct - operationalizing a SOA is hard, which is why we see so many frameworks focused on cloud microservices today.

No, the reason WCF exists is to share data between programs. It wasn't just for SOA it was for everything.

Your over enthusiasm for WCF seems to stem from your own lack of understanding of the major uses of WCF, you're citing a minor use case of WCF as if it were the primary one.

Also the hints you're dropping of your work programming environment sounds like a beauracratic nightmare.

Read the first sentence:

https://msdn.microsoft.com/en-us/library/ms731082%28v=vs.110...

> Enterprisey doesn't mean designed to work in an enterprise.

It kind-of does, though "work in" might be more accurately stated "sell to".

enterprisey:enterprise :: militant:military

This. I've been using ServiceStack pre-commercial for over two years. The clean, flexible, RESTful routing and lean extensions are a breath of fresh air compared to previous frustrations with the hodge-podge WCF 'REST toolkit'. Mythz as an architect and maintainer is spot on.

I had thought that MS might be on it now with Web API, but your comment suggests not.

Is ServiceStack OSS being maintained by a community?

Don't think so. There was some discussion following the announcement but it never came to anything afaik.

The time and effort mythz et al put in would more than justify paying for a license vs taking on the mantle in my case.

The only good thing about WCF is you can easily add a service reference in Visual Studio. Which lets you immediately proxy it to JSON with Web API: https://github.com/jpsingleton/Huxley :)

Web API is great but actually came out of WCF despite being more like MVC (https://wcf.codeplex.com/wikipage?title=WCF%20Web%20API%20is...). Older versions used to serialise dates in a weird way but the latest version uses JSON.NET which is awesome.

I used to use ServiceStack and it was great although I hear even StackExchange are moving away from it now (https://blog.stackoverflow.com/2015/05/stack-exchange-podcas...). BTW use the StackExchange Redis client over the ServiceStack one as it's not properly thread safe.

The ServiceStack.Redis client uses pooled ThreadSafe Client Managers by design: https://github.com/ServiceStack/ServiceStack.Redis#redis-cli...

Which works very much like a DB Connection, where the Connection Factory is thread-safe (and what's used to resolve connections) whilst the DB Connection instance it returns are not.

Sorry, I know you worked hard on it but this comes from real experience. We had an absolute nightmare debugging strange issues in the cache and traced it to this. Probably an older version though.

Each threading issue reported ended up being traced back to sharing a RedisClient instance across multiple threads, e.g. by using a static RedisClient instance, registering RedisClient in IOC, etc - i.e. instead of using one of the ThreadSafe connection factories. If you have any repro showing any multi-threading issues with proper usage we'd love to hear about it (https://github.com/ServiceStack/Issues).

It was quite a while ago now but I wouldn't be surprised if we were using it wrong when combined with our DI config. :)

What would be your opinion on redis on a windows machine? Is it "production" ready?

azure redis cache service uses redis on win so yes

I couldn't find it, but couldn't it be on a linux box on azure?

I really liked Webservices in ASP.net when they were new, really easy to set up and you just had to add an attribute to the methods you wanted to expose. With WCF they went too far in covering all enterprise scenarios.

It would have been better if they kept and maintained a streamlined alternative. Forcing everyone to deal with the complexities of WCF isn't developer friendly.

This is a common anti-pattern in frameworks where they grow until they are a kitchen sink monster instead of splitting of into different frameworks streamlined for different purposes.

I agree with the gist, but I'm curious as to why you would use WCF when there were simpler existing solutions (eg. Web Services)? If you simplified WCF to decoration via attributes, what do you gain over ASP.net Web Services?

as long as you don't need any of the features of WCF you shouldn't of course (though I think webservices become an obsolete technology).

As soon as you run into edge-cases with authentication, compression, binary formats etc you'd have to use WCF. I think many use WCF "just in case" they need those features

Considering I've went from http to tcp services a number of times for improved performance, and you can simplify WCF clients a LOT via convention, it really isn't that bad...

When you are building WCF services and clients, in conjuction with a DI/IoC framework it can work REALLY well... I wrote an extension for MS-Unity that would generate service clients from a simple app settings string for the resource endpoint... that would automagically create a generic client on the fly in production.

For the server-side mounts, I had utility methods to mount several services into a single MVC web application, and it was just about seamless... for the project there was a base interfaces project that defined the services, so that the client and implementation were abstracted from eachother. It really was pretty slick in the end, and far from the default visual studio implementation.

I've also used WCF services as a message bus between a Flash/Flex simulation front end, and a connected backend service for that simulation instance. It wasn't bad.

That said, I much prefer to use node.js and simple JSON RPC and/or REST services these days over http or websockets (socket.io/sockjs), depending on what is pragmatic. It wasn't an option 8-9 years ago.

Good interview with the creator of Servicestack from a few years ago, http://www.infoq.com/articles/interview-servicestack

+1 for Nancy. A very intuitive and mature framework.

Agreed, though it can be hard finding documentation that covers more complex use cases.

There is also http://openrasta.org/ (not used it though).

IIRC WCF was used in CSLA to allow 2-tier apps to turn into 3-tier apps with just a config change. Probably the only good thing about it.

+1 Service Stack. Greatness.

>If you want to make a RESTful API with .NET WCF is overengineered for this, but this doesn't necessary means that WCF sucks. Right tool for the right job.

The last time I used WPF was for IPC - and it worked pretty well for that use-case.

> design your messages first and then figure out what the URLs should look like.

This is exactly what WCF let me do though and I wasn't limited to using HTTP like the others you listed. I was able to use a full duplex binary tcp channel instead.

I thought WCF was more hassle than it was worth. Then I got a massive performance boost from switching to the TCP transport with a quick configuration change ...and had fallback to HTTP after writing a few lines of code. Making the transport orthogonal to other concerns is a big win.

Rofl. Good luck with that. 99% of the people don't even know wtf's WSHttpBinding.

This wasn't for a public API. It's employee-use-only business stuff; both client and server are bespoke.

Reply on news.ycombinator.com