artodeto's blog about coding, politics and the world

By Bastian Hofmann and Volker Dusch The talk is about application architecture from the code site. Both are from ResearchGate Speak available on speakersdeck

What You Want

• good code review
• rapid development (even with big teams)
• handle large code bases
• frameworks to the rescue

Most Framework Are Dealing With Backend Or Frontend

• backend
  • symfony
  • zend framework
• frontend
  • backbone.js
  • jQuery
  • ExtJS

Frameworks Out There To Join Both Worlds

• mojito
• Meteor

How To Achieve The Goal

• incremental refactoring (take a look to flight)
• separate your code into components
  • clean interface
  • clean architecture
  • small teams can work on that

How Reasearchgate Have Done It

Classicla Webapplication Architecture

• loadbalancer
• webservers
• database
  • pgsql
  • memcached
  • mongodb
• services (rest services)

Webserver

• php templates
• lazy db queries in view
• yui
• duplicated code

We Could Do It Better

• try to compose your page out of containers
  • every component has to be self contained
  • can be addressed and rendered separately (by pure html response or json/xml data that is rendered by javascript on the client)
  • javascript is part of the component (easy up refactoring)
• initial page request is returning a simple html page as response that is triggering a lot of ajax calls
• if ajax request returns a ok, the return contains the updated data or handles the error (hint, on the backend, a "read from master" flag is added to retrieve the most accurate data without running into master/slave replication problems)
• share code between server and client
• templates, validation, entities
• create "a widget"
  • php controller (providing data)
  • ...
• do not fetch data directly (because it is painfully slow)
• require stuff (search for "evolution of code design at facebook" at infoq)
  • fetch requirements in a preparing step
  • batch requirements by calling resolvers
  • resolvers talks with services (multi-GET)
  • services calls connector interface (databases for example)
  • fetching data from connector
  • distribute back all the fetched data
• entity requirement
• service requirement
• request cache
• Multi-Get (get multiple data via one request for fetching a lot of data)
• requirement vs. optional
  • optional, template will be rendered without that data
• data dependencies within a widget by using callbacks (to create a dependencies and dataload workflow)
• php 5.5 generators by using yield
• data dependecies between widgets by using data requirements (fetched from the require stuff above)
• looks like this is complicated to debug by using symfony debugging tools (for example ;-))
• rendering (by using mustache)
  • [x]html
  • json
  • v8js for rendering templates on the server (rendering mustache templates is faster in javascript then in php) and to provide a single place to render templates (cool!)
  • use models in javascript to stop messings things up
• enables developers to only focus on their components
  • single place for refactoring
  • moving ugly code to one point
• easies up testing (also with faked data)
• error handling is simplified
  • remove component from the view
  • try to rerender it later
  • display a generic component
• a/b testing is easied up (removing "long hanging fruites" - that just made my date :-D))
  • create multiple components and simple render then via a/b testing on the frontend
  • read bandit algorithm on untyped
• by usgin "" you can use varnish to speed up the page
• easy reusing of components ("take that button and move it or use to somewhere else")
• mark components to load them asynchronous
• use "placeholder" with "placeholder data" for search engines
• try to use BigPipe (published by facebook)
  • compute as much informations as needed (like navigation) and then flush this to the client
  • render and flush some javascript logic
  • start computing the first body (kind of heavy work) that holds javascript logic and data to replace rendered and flushed content from the top
  • repeat that until you have finished creating the initial datas
  • send the final flush with the html end tag
• fast changes on the frontend by replaceing only the components that have to be updated and use javascript push to change the url