We are all building products - web products , ours or other's; or dreaming about it. And Rails, Agile and Sound OO design makes that simple. As simple as following well laid out instructions ( assuming off course, that a viable idea has first come out of *somewhere* and has *someone* chasing it).
What I intend to do with this talk is to ponder, publicly, on the consequences of introducing a simple design decision while going about *initial* brick laying - splitting the product into separate API and front_end processes from the very start; and consider the tech and biz consequences of this over time.
Duh. An API sounds very elementary; especially if your product is designed to have multiple front_ends spanning the web and mobiles. I would still think this an open topic and an excellent way of spending 25,000 minutes of collective time and here's why:
* I saw this decision taken on a project when it was spawned on which I ended up spending 3 years (and foreseebly another 5 years) on and have been wondering why ever since.
* Over the years, I have alternatively defended and opposed this design principle on grounds of - business scalability, over engineering, maintenance costs
* I have effectively used this design decision to generate drastic business viability in terms of: branding A/B, product pruning and A/B testing, 3rd party vendoring of front_end apps, localization and internationalization
* I have seen the technical consequences of this action play out: initial engineering overhead, cost bonus on front_end revamps, modularity and malleability of core business logic, offshore_ability of front_end modules
I aim to keep the talk lighthearted and with brevity in mind, intend to run through the core idea of a split, common rants, the trade-offs and consequences, business scalability and viability that this achieves, technical and maintainability consequences, ActiveResource and it's limitations, and my vision of the ideal JSONified almost_RESTful API approach.