Sessions at Keeping It Realtime Conference 2011 on Tuesday 8th November

The structure of web applications is changing. Requirements are changing, technologies are changing, and most importantly user expectations are changing.

Realtime is part of a larger shift in the structure and design of web applications. The old patterns we used for previous generations of applications will not hold up and we need to move on to something new.

Mikeal writes code, he used to work at Mozilla, CouchOne, and Yammer. He has a new thing he can't tell you about or else he'd have to kill you. Mikeal contributes to node.js and writes many widely used node.js modules and is the curator of NodeConf.

Despite the hype, the realtime web is just an extension of the age-old messaging world into the realm of the web. During this time, we're dealing with the frustrations of a transition period. We're moving from hacks to standard protocols and browser adopted technologies that will give us a more realtime web. There is a lot of confusion as people catch up on basic networking concepts and advance into messaging concepts. There is instability of platforms and libraries as standards shake out and developers actually realize the state of the art.

Let me show you the future. It takes the existing future of messaging systems and brings it to the web. It's a JavaScript library and standards based protocol stack called NullMQ. It gives you ZeroMQ for the browser.

As web developers realize the shortcomings of big MQ systems, a few are starting to grok the power of ZeroMQ, the next generation of messaging toolkits. Unfortunately it's out of reach to the browser and JavaScript. More importantly, it should be. There are inherent properties of the web and browser context that don't match up with ZeroMQ. But there's still a lot of power there, especially if you could interact with ZeroMQ based backends as if you were another ZeroMQ socket in that backend. This isn't Mongrel2, and it's certainly not socket.io, this is ZeroMQ-like sockets in the browser. And it's built on top of existing standards, based on the concepts of ZeroMQ.

We're not reinventing any wheels here, or making up our own protocols or APIs (like other JS messaging libraries). We're just adapting proven solutions to a new context to solve real problems. In this talk, we'll show you a preview of NullMQ, what it can do, what it's built on. Mostly it will be a discussion.

Hopefully your mind will be blown.

People want to build realtime-enabled web apps right now, but WebSockets aren't ready yet. Various web messaging services are being build to address this.

In this talk we'll discuss the ingredients of realtime web apps, why third-party web messaging services aren't going to help in complex scenarios, and why generalizing messaging problems is not going to work within the web context.

We'll also present the SockJS project - our attempt to help building realtime web apps. As opposed to other solutions, SockJS is not a magical black box; instead it's a robust and portable building block for web applications.

https://github.com/sockjs/sockjs...
https://twitter.com/#!/sockjs

About Marek Majkowski
After fruitful encounters with topics as programming industrial robots or exploiting every hidden feature of TCP/IP options for tracingn etworking traffic, Marek settled for 'scalability' as his main field of interest, one that he attacks with a magic sword labeled 'asynchrony'. He likes to keep asking 'Does it scale?'

Marek works in London in the RabbitMQ team, a division of VMWare. He enjoys London, though he had to trade riding motorbike in Warsaw for daily commuting by tube.

http://www.rabbitmq.com/blog/
http://twitter.com/majek04

(And it's probably not why you think.)

With html5 and web sockets, it is now possible to extend native protocols like STOMP, XMPP and AMQP all the way to the browser. Messaging platforms like JMS and AMQP are ideal for building real time applications, and when extended to the browser via web sockets and Javascript, they become game changers for building scalable real time web applications. In this talk, I will show you how to go from zero to sixty in a pure javascript world with a node.js back end messaging service running on a RabbitMQ broker, and manipulating a native AMQP stream over web sockets via Javascript in the browser. We simply use a Kaazing gateway to relay TCP traffic over web sockets to fan out the broker all the way to millions of browsers simultaneously. Messaging brokers and TCP to websockets relay gateways can also be leveraged to implement peer to peer, browser to browser capabilities.

When we say “realtime” in a web context, we generally think about Websockets or comet (long polling or streaming). Those are often the best options when a browser is involved (let alone native push on some mobile devices).

But let’s think out of the browser for one second, and review other options. Do we want all our services to talk among one other using HTTP? What about DNode, or ZeroMQ?

We will review a non-exhaustive list of some awesome tools that can help you to develop better realtime apps. Have one node handle millions of concurrent connections, hundreds of thousands of queries per second.

Moving to deployment options, we will discuss how we apply these concepts to run realtime apps at scale on dotCloud.

Half sysadmin, half developer, Jérôme is now working at the PaaS provider dotCloud, where he wears the hats of Evangelist, Support Ninja, and Ops Guru.

Before joining dotCloud, he also co-founded Enix, french provider for cloud and virtualization services since 2005. He holds a Master's Degree in Fundamental and Applied Computer Science from the University of Marne-la-Vallée in Paris, France.

When he's not hacking on his computer, he can be seen cooking, or heard playing the piano, the bass, or the theremin.

You wouldn't use a fork to eat soup, you'd use the right tool for the job.

Aaron Blohowiak, author of Transitive.io, talks about decisions that every realtime framework designer has to make, describing the advantages and drawbacks of each choice so you will be able to design or chose a framework that makes the right trade-offs for your problem.

Considerations include:

• When do updates spread? implicit vs explicit state propagation
• What about race conditions? Locking vs Last-Wins
• How do components communicate over the network? RPC vs message-oriented
• Who is responsible for deciding how the HTML should change in the browser? Smart clients vs Smart servers
• Do we need to support web crawlers or offline mode? SEO vs SPA

Node.js provides a beautiful new platform for building realtime applications as long as you are not running on Windows.

That story is changing.

Come to this talk and see how Windows is becoming a great place for developing and deploying node.js applications, whether running on-premise or in the cloud.

Kicksend's a new realtime filesharing and content delivery platform.

In this talk, I'm going to cover our architectural design decisions, the realtime stack we're currently using, the integration issues we faced, launching to the public and managing buzz-y marketing press for an application that's very realtime.

Throw out everything you know about scaling. Real-time is a whole new ballgame. I'll cover share my in-depth expertise on how I created a highly concurrent, low-latency real-time web architecture at Flotype, with an emphasis on profiling, gathering metrics, and even some OS-level tuning.

Sridatta Thatipamala is cofounder and engineer at Flotype, specializing in scalable, high-performance real-time web systems.

Henrik Joreteg and Alex Payne interview authors of several frameworks

We live on the unexplored frontier of the real-time web. Current applications inspire and amaze, but new ideas and products are still waiting to be discovered and built. Current tools make it easier to do what is already possible, but how will we accomplish what is today considered impossible?

How will we build a web-based MMORPG or a first person shooter? How will we handle data exchange when every part of our app is a collaborative experience? How will we deal with combinations of future real-time services that must all work together?

In this talk, I'll introduce some ideas that may be helpful for the next generations of applications.