In part 2 of Phil Leggetter’s guide to realtime PHP apps, we take a lightning tour of the many options available to developers.

Building Realtime Web Apps with PHP
Keine Kommentare

In the first part of this two part series I discussed the history of realtime web technologies and how using them directly in PHP may come across as being difficult. I also promised that this part would provide the information required to solve that problem. So without further a do here are a number of great solutions that make it possible to get the benefits realtime provides into your PHP stack with minimum effort.

Realtime Solutions for your PHP Stack

There’s no getting away from the fact that realtime is still harder than it should be. Using an existing solution is by far the simplest way to start building realtime apps in PHP, and also poses the least amount of risk for hair-tearing, face-palming, head-desking, and table-flipping.

The best way of using a realtime solution in your PHP stack is to use it alongside your traditional web stack and communicate between the two components using either message queues or web services. Having a loose coupling between these two components is actually quite nice as it means you can more easily test the integration and swap components in the future.

PHP Solutions

There are two PHP solutions that are worth taking a look at – but straight away I would take note that I probably wouldn’t use these in production since they don’t offer connectivity fallback.


Ratchet is a PHP 5.3 library for asynchronously serving WebSockets. You need to run the application you build using Ratchet as a daemon and communication between your web stack on Ratchet-based application is recommended to take place over a message queue. In fact, there’s an integration tutorial which covers just that.

Ratchet also provides a pub/sub abstraction via a WebSocket Application Messaging Protocol implementation which should make it easier to get started.


Wrench provides the barebones required to create a WebSocket server and provides a nice way of registering multiple applications with the same server.

Without developers using these technologies they won’t be updated and maintained so I would recommend that you try both Ratchet and Wrench out. And, if possible contribute to the projects to encourage growth and improvement – that’s one of the great things about open source.

Side-by-Side Solutions

Since you’ll have a loosely coupled architecture it leaves you free to use a realtime technology written in something other than PHP. And if you want to self-host the realtime part of your application, using another technology alongside your PHP web stack is by far your best option.

There are lots of realtime web technologies to choose from but here I’ll select a few based on popularity, functionality and ease of use.


Socket.IO is the probably the most well known and popular realtime web technology. It’s a Node.js library that now has numerous ports for other languages. This means you can run the server implementation on the other supported technology stacks but use the same client libraries (JavaScript, iOS, Android etc.) to connect to it.

Due to the uptake of Socket.IO there’s a large community backing which can really help development. On the downside, the docs can be a little sketchy. For example, at the time of writing the website docs cover using 0.9.x whereas the github readme covers 1.0. Also, it can be quite difficult to find useful functionality like rooms as it’s buried inside the github wiki.

Socket.IO has a lower learning curve due to a large community of developers who are happy to help with n00b questions. On top of that, the continued expansion of its market share means it will get even better.

See the recent Web & PHP article on Integrating Node.js with PHP for an example of using PHP, memcached/redis and Socket.IO.


Faye is a solution which offers a simple pub/sub abstraction and has full fallback support. (Well, actually it follows an upgrade strategy, but it’s the same net result.) What all this means is that it will serve most application’s needs and will work in 99% of browsers and network envirnments.

Another great thing about Faye is that it’s available in both Ruby and Node.js flavours, and a lot of thought has gone into securing your realtime application with faye. All this means you’ve got all the pieces you need to build a production ready realtime web app.


If you want to work close the barebones of WebSockets on the client, but you also want the benefits of fallback support, then SockJS is a great choice. SockJS provides a „WebSocket emulation JavaScript client“ and has servers available in Node.js, Erland, Python/Tornado, Python/Twisted and Java. It also has work-in-progress servers available in Ruby, Perl, Go and Haskell.


SignalR is an open source solution for ASP.NET which is now an official part of ASP.NET. It provides full connectivity fallback support using a variety of solutions.SignalR is particularly interesting because it offers a simple Persistent Connection API but also a Hubs API. The documentation tends strongly towards using Hubs.

Hubs offer a way of defining objects on the server and SignalR creates proxy objects in JavaScript which you can interact with from your own application JavaScript. The SignalR docs describe this as:

The SignalR Hubs API enables you to make remote procedure calls (RPCs) from a server to connected clients and from clients to the server. In server code, you define methods that can be called by clients, and you call methods that run on the client. In client code, you define methods that can be called from the server, and you call methods that run on the server. SignalR takes care of all of the client-to-server plumbing for you.

I think this is a really interesting concept and can really help productivity. But I do think it has the potential of resulting in a lot of network activity as methods are called; server to client and client to server. The fact you are simply interacting with an object may mean you forget each call can equate to at least one message being sent over a network – potentially more. This could result in application lag due to network latency and increased resource usage. So, if you use SignalR Hubs in parallel with your PHP web stack please keep this in mind.

Hosted Solutions

Hosted services are more popular than ever. They offer a great way to offload a lot of complexity, letting you get on with building feature functionality into your application. So, it’s not surprising that using a hosted service along side your PHP stack is an option when adding realtime functionality into your app.

I used to work for one such company so it’s no surprise that I believe this is the best solution when adding realtime to your PHP application. Here’s why:

  • You can still do everything in PHP
  • It removes the architectural complexities involved in running a realtime solution in parallel
  • You only need to consider scaling your web application, not your realtime infrastructure
  • You will be up and running much faster with a hosted service than using a self-hosted one

As shown in the realtime web tech guide, the types of realtime hosted solution can be broken down into two categories based on the functionality you require; messaging (pub/sub) and synchronisation. I’ll first cover the most popular messaging options and then the synchronisation ones.

Finally, hosted services tend to provide access to their service in two ways. The first is to use a library within your application client to create a connection to the service. This means that whenever new data is available it can be pushed to the client.

In addition, these services also offer web APIs that provide access to functionality such as publishing data through to the connected clients. This last point is core in thinking about how you integrate your PHP backend with the service.


Pusher (who I used to work for) is fundamentally a realtime messaging service. What makes Pusher great is its simplicity and ease of use.

They offer server and client libraries; server libraries for publishing data and providing helper functionality, such as subscription authentication and querying application state, and client libraries for subscribing to data, requesting authentication, and also publishing data when authenticated. Pusher have consistently championed WebSocket technology, but do offer fallback connectivity solutions.

Pusher’s docs have all the information you’ll need to build a realtime web app. Their developer tools offer an extremely clear debugging tool to quickly spot—and squash—application bugs.


PubNub is a realtime messaging service with the added bonus of also offering native Push Notification support. PubNub have a large number of libraries, covering a multitude of platforms, and all tend to offer both pubsub functionality so you get the same functionality no matter the runtime.

Right now PubNub only offer HTTP-based connectivity. So, whilst you get the benefits of reliable connectivity through proxies and firewalls on virtually all browsers, you don’t get the benefits offered by WebSocket technology.

With the recent introduction of Push Notifications and what looks like a high percentage of their customers building for mobile, PubNub may be the best solution at the moment if realtime on mobile is part of your offering. are another realtime messaging service and relatively new on the scene. They are worth a mention for the funding they received alone. This demonstrates that their investors at least believe that realtime functionality is going to be a true game-changer. offer WebSocket connectivity with fallback support offer a pub/sub API with associated libraries available for multiple languages, but also a language markup called XRTML.


Firebase are one of the first realtime services that I know of to tout themselves as a BaaS, or Backend as a Service platform. (This trend is continuing—check out What this means is that it’s possible to build an application without any backend, but that doesn’t mean it’s a requirement.

Firebase offer a REST API for publishing and retrieving data along with client libraries for JavaScript, Android and iOS. Since a key part of synchronisation services such as Firebase is persistence, their client libraries focus on working with data structures and providing ways of manipulating those structures and being informed of any changes that occur.

This is arguably a little more difficult to wrap your head around than simple pub/sub, but it is very powerful. Try out their tutorial to see just how easy it is. For another example of just how powerful this is you can see how I won the ESRI 100 lines of JS challenge by converting an app to be multi-user in just 5 lines of code using Firebase.

Firebase’s docs are well organised, comprehensive and easy to follow. They also have solid developer tools.


Simperium are another BaaS who were recently acquired by Automattic—the folks behind WordPress.

They use SockJS behind the scenes, and their client APIs offer similar functionality to Firebase. The main difference is that they use a concept called buckets—which are simply unique names—to identify data and not URLs like Firebase. This means you can’t access the internal of a data structure as easily as you can with Firebase (i.e. child nodes).

Simperium offers an HTTP API for integration with other technology stacks.

Further Reading

In the book Realtime Web Apps with HTML5 WebSockets, PHP and jQuery, Jason Lengstorf and I step through the process of building a realtime application on the LAMP stack, from concept and design through development. We made the decision to use Pusher because a hosted solution virtually eliminates the learning curve without sacrificing any functionality.


Realtime has come along way in the past 10 years, but now things are really starting to heat up. There are still a lot of details involved in managing realtime technology, but there are lots of technologies that have already done all the hard work for you; this means you have a lot of choices when adding realtime functionalty to your PHP web stack.

Unfortunately, right now there isn’t a production-ready full-stack PHP solution, which is why you so frequently see people suggesting your only solution is to use Node.js. Here we’ve demonstrated that it certainly isn’t the only solution: running a realtime solution in parallel with your PHP web stack is an option, as is using a realtime hosted service.

It’s important to understand why realtime matters, the history of realtime web technologies and the options available for adding realtime functionality to your web apps, but the best way to really understand the benefits—and how cool the technology is to develop with—is simply try it out.

Share your realtime projects with me on Twitter: @RealtimeWebApps

Happy realtime coding!

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.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Benachrichtige mich bei
Inline Feedbacks
View all comments
- Gib Deinen Standort ein -
- or -