Presented at Nordic APIs, September 2013

1. Evolving from a monolithic to a distributed
public API
2013/09/18 Nordic APIs
Matthew Gray - API developer
@portedegrange

2. Who are 7digital?
Open access to broad catalogue of fully licensed
digital music in 37 territories
22 million tracks
Open to partners, end consumers, developers
Consumer store : www.7digital.com
All accessed through HTTP API
http://api.7digital.com

3. Who uses us?
Samsung, Microsoft, Blackberry and many more...

4. Where we came from
Started as a side project to provide access to
catalogue
Single monolithic application
Written in C# .Net (webforms)
Lots of shared libraries with other applications
Single team developing API

6. Problems
Dependencies between API and other applications
Working on a massive, ever-expanding codebase
How to scale? Not possible to scale eg. search
independently of whole API

7. What to do?
Build internal APIs for specific functionality
The original API can route requests for a given
endpoint to the internal API replacing it
http://api.7digital.com/1.2/release/details?releaseId=12345
/release/details
ReleaseDetails.aspx
http://catalogue-internal.name/releases/12345

8. Making the change
Gradually move code from monolithic API to internal
APIs
Rewrite where appropriate
Slow evolution
No new version or “big bang”
Consumers should not see a change in behaviour

10. Internal APIs
Smaller codebases
Fewer dependendencies
Technology / OS independence
Easier testing & deployment of individual APIs
Monolithic API still exists as a facade, but only does
routing, authentication and other shared concerns

11. Changing how we work
Smaller, more focused teams
An internal API is a product with a product manager
Smaller work items
Fewer blocked work items

12. Internal APIs - downsides
Less consistency between APIs
Focussed teams = knowledge silos?
Fewer code dependencies but implicit dependencies
between APIs, datastores
More chaos

13. Limiting the chaos
Smaller APIs are easier to understand
Continuous delivery and single-click deployment
Measure things (statsd, newrelic, logstash)
Dogfood things (build your own apps on your API)

14. Keep consistency
QA
API standards committee
Document new endpoints upfront
Use a single schema

15. Share knowledge
Cross team pairing and collaboration
People can move between teams
Knowledge sharing sessions

16. Questions?