I was recently interviewed by Lee Dumond (@leedumond), Nick Berardi (@nberardi), and Dustin Davis(@prgrmrsunlmtd) for the latest Mashthis.io podcast. It was an interesting conversation in content syndication, app development, and using APIs to supercharge a content and platform strategy. 48 minutes is big commitment though, so I timecoded our discussion topics and added a few links for context. My favorites are bolded.
You can listen here. The audio is a bit choppy because of Skype difficulties. If you hear the same thing mentioned more than once, it’s probably one of our retakes.
Update 10/23/12
Nick Berardi asked a really important question on document databases vs. relational databases, and I didn’t answer it as well as his question deserved.
Nick noted the trend that organizations tended to have one relational database but that the document DB trend was “pick the best one for the job.” This is a hugely important insight, and there are two intertwined reasons: the intrinsic nature of the tools themselves, and the shift away from traditional client-server architecture to SOA/API-based architecture.
Document databases have so much variability between one another that you really have to pick the best tool based on the capabilities you need vs. the tradeoffs you’re willing to make. They differ by query capability, ACID compliance, clustering, retrieval speed, etc. On the other hand, traditional SQL databases might have 95% overlap, and you’d think that would make it easier to switch between them, but that last 5% has been so relied upon traditionally that it made lock-in the logical choice. Proprietary SQL syntax, stored procedures, or in the case of SQL Server DTS have traditionally been important features for querying and transforming data, and if you wanted to take advantage of them, you needed homogenous architecture.
That’s a good segue to the transition to data services — in our case, RESTful APIs. With standard interfaces you can untether yourself from uniform infrastructure. Your data services may not actually run as fast as if you were syncing databases with proprietary services, but you’ve given yourself more flexibility to pick the best tool and move quickly. Every shop has its favorite tools, but we’ve already used both CouchDB and Redis on small internal services and can see us picking up another document DB here and there as needed.
Beyond flexibility, there’s a lot to be said about developer happiness and productivity. Both come from exploring new tools and picking the right tool for the job. That’s worth a lot.
Mashthis.io: The NPR API with Javaun Moradi
2:00 – Is NPR a truly digital system or a radio system with a digital presence?
- My spiel on public radio vs. NPR.
4:14 – Getting 100+ local stations into the API
7:20 – What kind of APIs are under the hood in a mobile app?
- The NPR Music iPad app and the Infinite Player
9:50 – The challenges of streaming audio to mobile apps
13:00 – How has the API changed over the years….
- Changed the way we write REST APIs
- Moving at the speed of business and avoiding becoming big IT
- ZaPHPa – a micro framework written by Irakli Nadareishvili and other members of our team
- Story API permissions
16:40 – How do you decide when to write a new API?
19:40 – How do you keep up with documentation.
- dev.npr.org, powered by github/jekyll and I.P.A.
20:55 – Technology: hosting and programming languages
23:00 – Would we stay on PHP? How do we get more API speed?
25:50- What is this drupal project?
- The official NPR Digital Services Drupal plugin
29:00 – ElasticSearch + Document database.
- We had a *lot* of retakes around document databases.
- Besides speed of retrieval and flexibility, JSON is increasingly important to us.
31:15 – More on NoSQL databases
- I forgot to mention we’ve also used Redis.
32:42 – The future of connected cars. Will there be a standard among manufacturers?
- Will it be driven by smartphones like iOS and Android or by the manufacturers.
