Last weekend, I showed a very early behind-the-scenes preview of what will eventually be the next version of CoasterBuzz (the fifth major revision in 12 years) to some folks that participated in the PointBuzz off-season tour at Cedar Point. It's very early in the process, but I thought it would be fun to talk about some of the things that have changed over the years. This series of posts probably won't mean much to non-code-monkeys, but it's fun for me to write about and create some record of what I'm doing.
First, a little background. CoasterBuzz was first built in 2000 using the old ASP scripting platform, which was awful. The second version came shortly thereafter. It was awful in part because I wasn't particularly good at writing code, and had only been doing it for two years, without any mentoring. It wasn't until 2003 that it became an ASP.NET application, and that major platform change required a total rewrite.
Version 4 took even longer... more than five years, launching again in September, 2008. It ditched the home-made CMS that I built, but still recycled a lot of the underlying code. Nearly ten years ago, I liked to build data objects that included data access built into them. I wouldn't describe this as an awful practice, in part because I wrote about it in my aging book, but it's not great for testing. By that time, I had largely embraced test-driven (or test-influenced) development, but I just wasn't up to rewriting everything.
What that version did do for me is create a relatively stable platform to expand on. While it has been more than three years since a major revision, I've been able to add a ton of features that had real impact on traffic. I've been mostly happy with it.
However, there is still a bit of legacy in there, as old as nine years. The other thing that happened, just a few months after I launched, was the beta release of ASP.NET MVC, the framework that runs on top of ASP.NET to bring development back to what HTTP really is. I've been living in that world ever since. In fact, I did a total rewrite of the forum app in MVC, and POP Forums is available open source. There is a whole stack of goodness at my disposal now, from jQuery to EF. These are all things I'll write about. I don't have a timeline in mind yet for vNext of CoasterBuzz.
Right now, I wanted to talk about WCF, and how I've expunged it from my life. The promise of WCF has always been that you could expose and consume services wrapped in whatever protocols, and it would just work and be easy. Maybe that's not the promise, but that's what I was sold. I think what we got was something that's completely dependent on configuration, either in code or XML, and almost never works the first try. And if that weren't enough, putting in Azure has been a pain, in my experience.
Still, I decided to give it an earnest shot when I built a Silverlight-based feed watcher for CoasterBuzz. I liked that it could be out-of-browser, work on my Mac, and I needed a science project for Silverlight. Getting both ends of the chatting to work was a pain, but eventually I got it working. That was years ago, and whatever I've done with Silverlight since has been for Windows Phone, some DeepZoom stuff, and a file uploader.
Fast forward to today, and the next thing on my to-do list was to port over the service for the feed to vNext. It didn't work. Same config as far as I could tell, and obviously I didn't change the client. It just didn't work. It threw all kinds of ambiguous errors that didn't make sense. It was all coming back to me about how much I struggled to make it work the first time.
When I was still working at Microsoft, on MSDN/TechNet stuff, we built an API for one of our services using MVC. Think about how stupid-easy it is to make a RESTful endpoint using MVC. You can define the route and literally consume and respond with any bits you want. And it doesn't take long to do, either. It's no wonder that, a few years later, we see Web API surfacing with the next version of MVC.
So with the annoyance of WCF, I added a route to serve up the feed as JSON, and borrowed the helper class I had written for the CoasterBuzz Windows Phone app to talk to it, and I was done.
In a lot of ways, WCF shares an issue with ASP.NET Webforms. It tries to abstract away something to an extent that it starts to obscure the original problem. Both are fundamentally trying to shield you from the process of sending bits over a wire and doing something with them, and both turn it into something entirely different. HTTP isn't really that complicated in the first place, so why make it harder?
The common thread you'll see in a lot of my writing about this re-write is that I'm doing more with less code. Ditching WCF for simple JSON via MVC was a no-brainer. Next time, I'll talk a bit about replacing ASP.NET AJAX with jQuery.
Jeff, I like the take on WCF but for me I still have one particular use case where I love it still and have done some work to make that even easier which you may enjoy. The use case is this: TCP binary secure Windows client to Windows server communications over a LAN where HTTP is just a waste of overhead. See http://bit.ly/HM3FbT and let me know what you think.
I think you're a bit hard on WCF.
There is no doubt that it isn't as simple as we'd like, and as simple as we'd hoped for.
But in my book there's nothing that can simultaneously compare to its capabilities yet be (I shock myself with the next comment) relatively approachable to develop for and use. I say this coming from working with RMI, RPC, CORBA, ASN.1, etc.
I suppose you might say that WCF "sucks less" than the competition. I do concur it still feels needlessly arcane, but unless I feel like being married to one technology, I've yet to find something that is better. I stand by WCF.