Transcript of "Project Timbit"

1.
Project TimbitDiving into a new web development paradigmAugust 17, 2011 - Presented By Edward De Groot, Director Of The Postmedia Digital Innovation Team

2.
Introduction✤ Postmedia’s Digital Innovation Team is ﬁnally up and running✤ We are not about building new frameworks for CMSs but... ✤ Need a platform to quickly build new prototypes and functionality ✤ Want to assist the Professional Services team in expediting development, testing and deployment of widgets and templates ✤ Need something to keep us busy and out of trouble ✤ Want to contribute to the web development community✤ You are encouraged to comment and/or ask questions

4.
The DigitalMedia Problem✤ Most digital media sites are (overly) content heavy✤ Most incorporate (too much) content from many different sources on a single page✤ e.g. canada.com home page ✤ Built utilizing over 100 widgets. ✤ 80+ feeds from our CMS alone ✤ It’s not alone.

5.
Possible Solutions✤ Utilize caching wherever and whenever possible ✤ Already do that via Akamai, MemCached, etc. (That’s why canada.com, as big as it is, still renders on the server in < 1s on average)✤ Reduce number of widgets / page size ✤ Ideal, but we will always be somewhat content heavy✤ Render widgets in parallel! ✤ Both obvious and promising...

7.
Better, but not Great.✤ The majority of widgets render data from remote data sources (Databases, REST APIs, etc.)✤ I/O calls introduce signiﬁcant latency✤ Therefore, most widgets, under load, spend most of their time waiting for data✤ In concurrency-based, multi-threaded applications with signiﬁcant I/IO, high loads will result in most threads being blocked. The result? ✤ High CPU/memory utilization (signiﬁcant context switching) ✤ Low throughput (lot’s of blocking) ✤ High request queuing

8.
The Main Event✤ Event-Driven architecture solves the I/O latency issues.✤ Much better at handling high number of concurrent users✤ Much better memory efﬁciency under high loads✤ No dead-locking, as there are no locks, no blocking calls.✤ As such, a widget can continue to service new requests while waiting on I/O for other requests.

9.
Node.js✤ An event-driven server-side JavaScript environment based on V8. It is intended for writing scalable network programs such as web servers.✤ Event-Driven libraries are available for other languages (Ruby, Python etc.) so why Node.js? ✤ In Node.js, event-driven is not an after thought. Less likely to accidentally create blocking calls, particularly 3rd party packages/libraries ✤ The merging of websites and native applications is inevitable. HTML5, CSS3 and JavaScript will (ﬁnally) enable and empower that platform. (my opinion) ✤ The lines between Client, Cloud, and Server will continue to erode. JavaScript enables our code to become portable. (more on that later)

10.
CoffeeScript✤ A programming language that transcompiles to JavaScript.✤ Adds syntactic sugar inspired by Ruby, Python and Haskell✤ Adds more sophisticated features like array comprehension and pattern matching.✤ Compiles predictably to JavaScript, programs can be written with less code with no effect on runtime performance✤ (ED loves Ruby, hates JavaScript, and drinks a lot of Coffee.)

16.
connect-esiEdge Side Includes tag processor for the connect✤ Main purpose (today) is to assist in testing widgets✤ Only basic ESI support so far ✤ esi:include (including nested) ✤ variables such as $(HTTP _COOKIE), $(QUERY_STRING) etc.✤ [DEMO]