Look Who it Was Random video

RubyConf India 2013 Graph Databases - Split In Between by NikhilVallishayee

165 views · Published 31 August 2013 · 45:43 · Indexed 24 October 2026

Channel: Confreaks · 2013 · Science & Technology

Watch on YouTube

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.

Help us caption & translate this video!

http://amara.org/v/FG9I/

More from this channel