On Fri, Feb 1, 2013 at 7:44 PM, Paul Glavich <[email protected]>wrote:

> Webapi is a reaction to attitudes as described below.****
>
>
[ ... ]


> Ofcourse WCF can do REST too, you just have to twiddle a few hundred
> different knobs on the right way. I would argue WCF is not bullshit. WCF
> comprises way more than REST and has a very good feature set (albeit with a
> some implementation flaws). Support for MSMQ, TCP, ServiceBus etc… all via
> config is no easy feat.****
>
> ** **
>
> >> you want to do an intermittently connected app then use some sort of
> message queuing framework/system or roll your own ****
>
> And the circle of development life continues…..
>

Abstractions are great when they exist for a genuine need. I'd much rather
write a computer game against DirectX than whatever nightmare you normally
use to talk to GPUs in assembly. I'd rather write a business app in terms
of SQL than managing structures on disk myself. The benefit of the scenario
with the abstraction vs without is decisive.

However when abstractions are thought up by some egg heads in response to a
need that doesn't exist, then you end up with something like WCF. The cure
is worse than the disease.

In the case of the two examples I provided above, the leverage you get from
the abstraction is clear. In the case of WCF abstracting rest - why? Even
if you wrote your REST calls directly using sockets, it is STILL trivial.
If I needed an intermittently connected app to use MSMQ, I could use MSMQ.
How many times have you heard of anyone writing an app and then after it is
done going "oh shit, we need to change the app to use SMTP instead of TCP
sockets." I mean WTF. Seriously. It is an abstraction that doesn't
abstraction for added productivity or anything else.

Case in point. I recall helping the developer hired by one of our clients
get a WCF service up and running on some of our infrastructure. We spent a
couple of days beating our heads against why it was failing before finally
determining that WCF assumes the existence of an HTTP host header when
generating some of its own internal URLs (which is not normally present in
on a fixed dedicated IP brinding). Failing that it reverted back to using
the machine's netbios machine name in some of its internal comms, which was
failing (again, in a high end hosting scenario the internal machine name is
never going to resolve on the Internet and normally sit because an app
accelerator or firewall etc) . Completely retarded behaviour and purely in
existence in and of and because of the abstraction itself. I could have
written all of the end-point communication for the project myself in less
time than it took to resolve that one issue.

In the debrief with the client:
<changed to protect the guilty> says:
 I see what you mean when talking about how WCF can be difficult to work
with. It's been a huge learning experience for me.
David Connors @ codify.com says:
 It is just too hard for what it does
<changed to protect the guilty> says:
 true

-- 
David Connors
[email protected] | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

Reply via email to