The popularity of applications such as Facebook, Twitter and Google+, and the increasing business value offered by products like Google Docs, Trello and solutions like Caplin Trader, have resulted in an expectation for web applications to be able to offer similar sorts of functionality and experiences. These applications are all examples of realtime web apps and are all powered by realtime web technologies.
In this two part series I’ll cover the factors we need to consider, and the options available, when adding this kind of functionality to PHP applications.
In the first part of the series, let’s make sure we’re all on the same page about realtime. We’ll give a brief overview that will answer the question, „What is realtime?“ as well as going over its history and underlying technologies.
What Is Realtime?
When we talk about realtime on the web it’s different to realtime in other contexts. For example, when a sensor detects a problem at a nuclear power plant, the time between the problem being detected and the safety mechanism kicking in really does need to be as close to zero as possible.
When it comes to realtime on the web, the primary focus is to deliver data within a timeframe that means it’s still relevant; it still has context. For example, information about a sports score change needs to be received while the game is actually still in play.
This isn’t to say that there isn’t a requirement for near-instant delivery of realtime data on the web. In fact, realtime web technologies were pioneered by companies like Caplin Systems in an effort to make it possible to deliver realtime data to traders. And in finance there’s a lot of money to be gained by having information before anybody else.
Outside of finance, the speed at which data can be delivered can result in increased opportunity; whether it’s getting a notification that a friend is nearby having a coffee, or seeing an edit made to a document and being able to instantly provide feedback. The ability to instantly share, interact and collaborate with others really is a core benefit of realtime web technologies.
The History of Realtime
In order to be able to instantly deliver information from a server to a client (a web browser) there needs to be a persistent connection in place between the server and the client, so new data can be sent over it. Traditionally web browsers use HTTP, which is built around the request/response paradigm where the client makes requests to the server (and not the other way around), so this was difficult to achieve.
Additionally, in order to build truly rich interactive experiences, the communication needs to be two-way. The server needs to be able to instantly send information to the client and vice versa.
Since plugin adoption was never going to be a mainstream solution, native solutions had to be created. This resulted in HTTP Polling, HTTP Long-Polling and HTTP Streaming methods. While these solutions worked, they were inefficient, with high client and server resource overhead. They also introduced potential for delayed data during reconnection periods and had to be implemented in different ways across each browser.
Since the range of solutions was so wide and varied, it’s no surprise that they have all been labeled as „hacks“.
You’ve also probably heard the term Comet before. This is an umbrella term used to group these HTTP-based solutions. Some schools of thought suggest that Comet was used to define solutions that were attempting to simulate bi-directional realtime communication between a client and a server, while others believe it was just generic term. Either way, it’s a hack and we need to move on.
Beyond Hacks: Server-Sent Events & WebSocket
In the same way that popular and highly useful functionality is making its way out of libraries like jQuery and into web standards (e.g.
document.querySelectorAll), the fact that developers were having to „hack“ solutions to achieve important pieces of web application functionality resulted in the web standards body taking note. This has resulted in two APIs; EventSource and WebSocket.
Server-Sent Events and the EventSource API use HTTP. The client implementation handles connecting and also reconnecting. If it can, it will maintain the connection to the server. If that connection drops it will reconnect. This, in-effect, allows for HTTP Streaming and Long-Polling solutions, thus can be controlled from the server.
Server-Sent Events are unidirectional, which makes them suitable for pushing messages from the server to the client. This can be fine in some situations, but when applications start to offer richer interactive functionality, communication really needs to go both ways. That can be in the form of direct user-generated messages (e.g. chat) or via more subtle communication in the form of changes to the data being requested. This latter point is consistently fundamental to applications, which is why very early realtime implementations often offered a pub/sub abstraction and had to hide the fact a second HTTP request had to be used to simulate bi-directional communication from the client to the server.
WebSockets to the rescue!
You’ll have undoubtedly heard of WebSockets and the WebSocket specification and API. It allows for a persistent, bidirectional, full-duplex connection to be created between a client and server. It represents the best way of communicating between a web server and browser. Do not be told otherwise!
The single connection and very small amount of data/message framing also means it is the most efficient and low-latency solution for realtime bi-directional communication between a web server and web client.
However—as always—older technology and infrastructure can stand in our way. Old web browsers don’t natively support the EventSource or WebSocket API. And some network infrastructure such as proxies and firewalls can interfere with connections. So, we’re not rid of the hacks just yet. We still need to rely on them as fallbacks in some cases.
Realtime can still be complicated
The landscape of realtime is still pretty complex: WebSockets are the best solution but we still need fallbacks; the fallbacks result in the requirement for a variety of hacks which work in different ways in different browsers.
What this means for developers is that we either spend a lot of time writing code to handle all these scenarios, or we let somebody else do that for us using a solution that already exists.
I’ve been involved in writing and maintaining realtime web solutions and now I would much rather use (and contribute to) an existing one whenever possible.
Are the only realtime solutions in Node.js?
So, there are some challenges facing traditional web stacks.
Apache Is Not Built for Realtime
In a recent survey, Netcraft determined that more than half the Internet is powered by Apache.
However, a fundamental problem is presented when building on the world’s most popular web server. Apache wasn’t built with maintaining many persistent connections in mind, it was built on the idea that requests are made and responses are sent back. This means that resources can be used up very quickly if requests are held open. This, in turn, means your app will likely require horizontal scaling in pretty short order.
There is an event MPM worker which has been „designed to allow more requests to be served simultaneously by passing off some processing work to supporting threads“. However, the lack of SSL support means that this won’t be an option for many production applications. Even if SSL wasn’t a deal sinker, Apache and PHP don’t directly offer WebSocket support, so you are stuck with HTTP-based solutions.
You’re probably now thinking „what about Nginx?“. Nginx doesn’t offer an application platform with WebSocket support. It does however offer proxy support for WebSocket connection.
Realtime is hard and adding realtime into your existing PHP stack may seem like it’s not an option. Don’t despair! There are still solutions available and, in the second part of the series, we’ll go into what they are and provide you with all the information you need to start planning on adding realtime functionality to your PHP web applications.
Phil Leggetter is a Developer Evangelist at Caplin Systems where he’s leading the project to open source BladeRunnerJS. He’s the co-author of Realtime Web Apps: With HTML5 WebSocket, PHP, and jQuery and writes articles for Smashing Magazine, .net magazine, Programmable Web, on his own blog and anywhere else he gets an opportunity to create content. Phil’s passions include developer experience, customer service are helping people realise the benefits of realtime web technologies, and then use them to build the next generation of interactive and engaging web apps.