SpringboardVR

SpringboardVR’s realtime requirements: WebSockets with global reach that are fast, reliable, and elastic

The core features of SpringboardVR’s platform are delivered in realtime:

• An in-headset VR content launcher

• Location, device & play-time management

• Online reservation system

SpringboardVR uses WebSockets extensively to power these features so users can manage incoming bookings and in-progress sessions, remote-launch and update games, and sync across devices. Their software needs to be highly reactive across multiple Single Page Applications, Desktop software, and VR software.

Unlike a traditional application where one user means one constant subscription, each SpringboardVR user generally means 10+ constant subscriptions anytime a location is open. Each VR machine is an active subscription along with web applications that operators keep open across multiple devices.

During the normal course of a day for SpringboardVR, this means 1000s of WebSocket subscriptions that need to be rock-solid, fast, and reliable across multiple continents.

This brings two major challenges:

• Deploying, managing, and scaling WebSockets that are reliable for 1000s of concurrently connected devices

• Maintaining low platform latencies and game load times for operators and gamers around the world

The journey to Ably via self-hosted WebSockets and Pusher

SpringboardVR is built on a Laravel back-end with a Vue.js front-end. As the platform has grown over the past three years the engineering team has cycled through various means of deploying WebSockets. Initially they set up a self-hosted Laravel Echo Server, then moved to self-hosted Laravel WebSockets.

The high operational overhead was a big strain on already-lean DevOps resources in a small, agile engineering team. Scaling up usage and services globally was a nightmare. “In the end,” says Matthew Hall, CTO of SpringboardVR, “running our own WebSocket servers was just taking too much time away from developing our core platform.”

In line with other components of their infrastructure, Matthew and the team decided that WebSockets belong with the likes of Redis Clusters and MySQL databases: something they simply don’t want to host, manage, or scale in-house.

They moved to Pusher. But over time Pusher’s single-region deployment equating to high latencies outside the USA, low network reliability, and an inflexible, tier-based pricing model forced them to search for an alternative provider. They found Ably.

The Ably Realtime Advantage

When searching for Pusher alternatives and testing various solutions, four things at Ably really caught Matt’s eye:

• Being able to deploy SpringboardVR across Ably’s global footprint of 15 datacenters and 200+ Points of Presence drastically improved reliability of their service while reducing average WebSocket latency across all locations by over 100%

• Flexible, usage-based pricing that just made sense when compared to Pusher

• Risk-free migration from Pusher to Ably with the Pusher protocol adapter from Ably

• A rich feature-set with SDKs compatible with Laravel Echo

By migrating to Ably, Matthew and his team gained access to a platform mathematically modeled and architected to guarantee message ordering and delivery without sacrificing latencies, fault tolerance, or service availability. This gave them not just an improved WebSocket implementation but also a rock-solid foundation for current and future needs.

Global deployment that’s performant, reliable, and highly available

Globally distributed across 7 datacenters and 635+ PoPs with additional guarantees around connection state recovery and message delivery, it quickly became clear that Ably was more than able to meet SpringboardVR’s global latency and network reliability requirements.

As a result, average latencies have improved for global customers by 100%, enhancing the user experience all round. The team also saved 100 hours plus per year in DevOps time and overhead, which SpringboardVR has reinvested in developing their core platform.

Pricing that makes sense

Ably’s flexible, usage-based pricing also better met SpringboardVR’s needs according to Matthew: “The pricing for Pusher just doesn’t make any sense. You’re stuck picking from four specific tiers no matter what type of application you’re building. What if you have an app that uses a lot of connections but a few messages? Or vice versa? Ably let us pick the usage we need across both connections and messages, letting us pay for a package that makes sense for us.”

Evidence-based, risk-free migration

For Matthew, being able to manage the risk of moving services was also really important. Ably is the only realtime platform that supports the Pusher protocol so he was easily able to easily carry out some evidence-based testing.

“To test Ably’s latencies and reliability, we initially ran both Ably and Pusher in production, sending events to both. This was super easy to do with the Pusher protocol adapter from Ably. Once we were satisfied and sure everything was working as intended, we were able to progressively migrate away from Pusher.”

Feature-rich and dev-friendly SDKs

Being compatible with Laravel Echo and Unity was essential. The team loved Ably’s .NET Client Library SDK, which they use for their Unity development. And Ably’s PHP documentation was clean and accessible enough that SpringboardVR extended the native Laravel Broadcasting system by building an Ably Laravel Broadcaster.

“We hope everyone falls in love with Ably as much as we have at SpringboardVR.” - Jamie Spittal, Lead Frontend & DevOps Engineer