APIStrat & APIDays Berlin 2015
3 likes1,595 views
This document discusses the process of redesigning the Mendeley API. It began as a monolithic codebase that had grown organically over 7 years, making it difficult to work with. The API team went through stages of denial, anger, bargaining, and depression before accepting that the code needed to be redesigned. They took on the challenge of tackling the monolith and splitting it into independent microservices. This led to the birth of API version 1, which focused on consuming clients, quick deployments, versioning, and other improvements. The final thoughts emphasize focusing on the long term, making services disposable, recognizing when codebases grow too large, and understanding client pain points.
APIStrat & APIDays Berlin 2015
- 1. 1 Mendeley The Story of the Mendeley API Joyce Stack / @MendeleyStack
- 2. World of Researchers 2 5 Build institutional Reputation showcase Impact find & win Grants Promote research expand Institutional network Fulfil Administrative duties Imposing researchers with many challenges & KPIs Doing Research But how about my PASSION?
- 3. Vision 3
- 5. 5 Background No. You cant have that.
- 6. 6 No we cant add more users No we cant add a column to that table No we cant do realtime sync No
- 7. Monolith 7
- 8. 8 Tackling the monolith. Were going on a dig.
- 9. What did we find? Different methodologies Custom MVC framework FIXMEs and TODOs Spaghetti junction of code Dead code 9
- 10. 10 Bargaining Maybe we can live with it, we can cope.
- 11. 11 Problems 7 years organic growth No independent release cycles Inconsistent standards Eternal version 1 API != product API with no client Privileged citizens
- 12. 12 Depression Whats the point? Its doooooooomed!
- 13. 13 Acceptance Just deal with it.
- 15. Reality Your first client will hate you You wont make them care about the new API You will compromise on design Your client will have specific behaviour You will feel REST symmetry pain You will feel that its never ending 15
- 17. Birth of API v1 Consuming clients Quick deployments Versioning Dog fooding A dev portal SDKs 17
- 18. 18 Final Thoughts The lessons learned bit.
- 19. Final Thoughts Focus people on the long term Software is not an asset Make services disposable Recognise when its too big Recognise client pain 19
- 20. Final final thought K端bler-Ross model of grief Its fine. Its not too bad Who can I blame? Maybe we can live with it Its too big a problem. Doomed Might as well get on with it 20 denial anger bargaining depression acceptance
- 21. Thank you 21 Find me on Twitter @MendeleyStack