ConfPad

Superficially, one might assume, that API development has devolved into a cookie cutter problem - pick a framework, let the developers CRUD it out - and with less complexity than an IKEA wardrobe setup, you have your endpoints. But when your API is replacing an existing high-volume application and has to ramp from 0 to 100 within seconds, the stakes are exponentially higher to "get it right". I would like to take you back in time, starting with the deceivingly simple one-line spec "we need an API to handle baskets and wishlists" and taking you step by step to the completed application as it stands now. As a product manager, I will first be focusing on laying the groundwork - how we realized our KPIs were irreconcilable and then identifying the hidden trade-offs to make it work anyway. Then involving our stakeholders to define the best possible data structures and endpoint behavior to make the switch from the legacy application as hassle-free as possible. Last of all: finding solutions to mitigate the issues you will inevitably encounter when tracking merchandise availability. Following the planning phase, I'd like to focus on the application architecture - particularly why Lumen was a natural choice, and how we played to the framework's strengths. This was crucial, as beside the standard trifecta of secure, scalable and maintainable, the Basket API also needed to be exceptionally fault-tolerant ... and would have to be built in three weeks. Last of all, I would like to review the ongoing maintenance aspects: how we approached logging & monitoring. The painful experiences we gained in backups. How we ensure that the API continues to be easy to integrate and extend. What we would now do differently in retrospect.