Mar 27, 2012 03:01 PM|John Galt|LINK
Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and
SELECT against your data source.
Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power
Thus the correct way is to request a projection against a data source that returns the exact information you want from the datasource and nothing else. As I used in my other post, if I want all of the Phone #s of a contact and I want to display only I would
Return Contacts.ID, Contacts.Name, ContactPhoneNumbers.PhoneNo. This results in a small data set that is quick both for the Database Server AND for the transmission over the wire and is memory efficient at every level.
However this is what Microsoft requires with WebAPI in the most common scenario of programming anything hooked up to a database (list data): Select Contacts.*, ContactPhoneNumbers.* FROM Contacts INNER JOIN ContactPhoneNumbers ON Contacts.ContactID = ContactPhoneNumbers.ContactID
Instead of returnning 3 columns of information you've returned every column in both tables. Given that the average contact table will have probably 20-30 columns and the Phone Number table could have 7 or 8, and likely there is a note field on the contact
that will be nvarchar(max) and could have a 2000 word essay written in it in HTML, you've now taken a paged source of 10 records from a few K from the server and over the wire to several hundred times that. Further the more results, the expodentially worse
And this doesn't bring up the memory usage issue. The SQL Server has to load all of that data into memory, then WEB API has to load it into memory once from the SERVER and then likely another time to stream it in their json/xml writer implementation. Thus
your web server is going to have memory issues FAST and so will your sql server (any SQL admin seeing what's coming over the wire with Web API will quickly put a stop to it's use for this very reason, to say nothing of the guys paying for your bandwidth and
your customers on less than optimal internet connections who will see a brutally slow app)
Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.
And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).
Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of
our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net
much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).
Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the
lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted
stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.
Wash rinse repeat.
I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference
between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added
new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)
Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario.
Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands.
Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think
they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.
Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.