Thanks, Matt. The app we created simply asked for permission to access the user's stream and status (read_stream, user_status respectively.) https://developers.facebook.com/docs/authentication/permissions/ The problem with that was that we had to basically interpret each content item in the stream to figure out if it was related to automotive. That wasn't easy since the link object that's exposed through the Open Graph doesn't give you much. That's why Howard and I started thinking about the best way to do this and we reached the conclusion that only a restructuring of the data will resolve this issue. Also, it seems like a the next logical thing to happen considering the push for structured data by Google. Facebook has a golden opportunity to truly be the ultimate destination on the web. If I can transact on Facebook, why would I leave it?! This won't hurt the other companies that partner with Facebook. On the contrary, it will boost their conversions and help the business grow. The idea of bringing traffic to your site is dying fast. The future is to be part of an ecosystem that works, and today that ecosystem is Facebook. Power up your APIs and join forces with them. At the end of the day, it's the user experience that'll matter. Are you into machine learning these days? Have you spoken to Paddy about it? He's been looking into it too. Good to hear from you, man :-) Cheers, Ismail

Hi Thad, Thanks for the feedback. You are absolutely correct. The solution we devised worked great for us precisely because we "only" use doubleclick ads. We haven't had the chance to look into the other ad networks to see how they fare on this system, but would love to collaborate on that. I like your alternative solution and I think it's cleaner. I'll give it a whirl :-) Thanks again for the feedback! Cheers, Ismail

I'm so bummed I missed that keynote. I'll check the infoQ site for the video later. You said, "if the idea is not working don't agonize over it, kill it and move on." I've always found it difficult to determine whether the idea itself is not working or some aspects of it aren't. Is it the idea itself or how I'm prototyping it that's not working? Is it the idea itself that's not working or is it just outside what Steven Johnson calls the "adjacent possible"? Is it not working now but could be working 5 or 10 years from now? How do you distinguish "good" ideas that aren't possible today for reasons A, B, and C from downright bad ideas? What do we look for to help us make that distinction? Apple was experimenting with what eventually became the iPhone for 6 years before the product first hit the market. I'm pretty sure the idea in its first iterations wasn't really working but they continued iterating over it and now we have what some might argue to be an "indispensable" product. What made Apple continue its efforts and not toss the whole thing out? I'm not really sure there is a clear answer to this, but it might be worthwhile to compile a list of "signs that your idea sucks" to allow people to identify the telltale signs of really bad ideas that just won't work. Ever.

Maybe another way of thinking about is asking the following question: what are the unacceptable outcomes when a service request times out or fails? Maybe by clearly identifying what we "don't" want to happen we can find out what the best solution is.

Great roundup! I agree that Lesson 1 (run your services as a remote service from the service client) was a big revelation, considering how unintuitive it was. Also, Lesson 5 (caching) could address any performance implications that might arise from implementing remote services. So in a way, the drawback to Lesson 1 is taken care of by Lesson 5. Randy Shoup of eBay made a statement in one of his presentations that I thought was very interesting. He said, "the consumer needs to be able to recover when its dependencies are down." If an application (i.e. consumer) is using a remote service, how could it recover gracefully when that service is down? Could a local cache at the consumer layer be an effective failover mechanism, especially for read-only service calls? Should it just stop working and notify the user that an error has occurred? These are some of the questions we'll have to tackle as we open up our platform next year. The fact that we expect 3rd-party developers to use our services in a way answers your question about how much visibility the developer needs to have into the architecture of our services. I think that answer is: none. All the developer needs to care about is what methods to call and what data is returning and in what format. The fun details should be hidden, I think.