REST APIs are Killing Your Real-Time App

by Brad Johnson, on May 7, 2019 1:17:17 PM

animal-animal-photography-blurred-background-833020

We need to have a serious talk about "real-time."

These days, it seems like there are more real-time Web technologies to choose from than trendy superfoods (see: Irish black pudding, cockroach milk). With the verifiable glut of open source technologies claiming real-time capabilities, you’d think that building real-time apps is easy. Spoiler: It’s not. The reality today is that building real-time apps is complex, time-consuming, and unintuitive. There are real-time databases and real-time messaging protocols; real-time message brokers and real-time application servers. But the goal isn’t to choose an open source point solution for its own sake. We suffer through integrating, testing, optimizing, and scaling these solutions because we want to build real-time apps. Herein lies the problem: Integrating together a bespoke solution of distributed open source components rarely results in a performant real-time app.

So what’s the difference between an app that’s architected with a collection of real-time technologies, and a real-time app?

The difference is the APIs. Ever since Roy T. Fielding descended from the mountaintop carrying his doctoral dissertation, Architectural Styles and the Design of Network-based Software Architectures, Representational State Transfer (or REST) has been the dominant model for state transfer on the Web. REST institutes a stateless model for Web services. According to Fielding, “REST's client–server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components.” In other words, REST enables developers to build and scale data stores independently from Web services, which can simplify application design and operation. However, REST also imposes a request-response model for state transfer, which is antithetical to the notion of streaming.

Streaming data, unlike a static document, is continuously generated and highly variable. Therefore, chunking data streams into sequential REST loads inherently diminishes the real-time nature of a data stream. This remains true, even if messages transmitted over WebSocket or other streaming mechanism. Even if data is streamed from point-to-point, the use of REST APIs ultimately makes real-time unsustainable for REST apps. Because REST loads are typically processed sequentially, data volumes can quickly overwhelm message queues. As such, devops teams are perpetually in a battle to manage load balancers, message brokers and databases as they struggle to keep up with real-time app state.

WARP: The New API on the Block

While REST APIs remain a viable approach for static data, it’s necessary to provide a stateful “hot path” to efficiently utilize real-time streaming data in a web app. This requires using an API designed for streaming data, such as the WARP API used by Swim.

So how is a streaming API, like WARP, different from using a REST API over WebSocket?

While WebSockets enable us “to open streaming connections to URIs, [that] only solves part of the problem. Apps need to open a new WebSocket connection for every URI to which they want to connect. This limitation prevents WebSockets alone from serving as a streaming layer [for Web apps].” Alternatively, “WARP is a protocol for multiplexing bi-directional streams between large numbers of URIs over a single WebSocket connection.” Instead of request-response, WARP creates persistent bidirectional links between Web services. This allows Web services to continuously listen to other data sources for state changes, or to update other Web services when their own state changes. 

But it’s not enough to just use a streaming API. Having a multiplexed streaming protocol also requires a stateful app server to efficiently implement it. WARP APIs enable stateful data processing by including relevant state information as part of the data stream. This provides the raw materials needed for a stateful “hot path” approach to streaming data, which can be implemented in parallel to standard stateless cloud architectures. Furthermore, using a stateful app platform such as Swim enables the conversion of stateless REST data sources into WARP streams, which can be combined with real-time data sources on a single, stateful app plane. This approach simplifies data unification and ensures your application maintains a consistent view of reality at all times. You can read more about the WARP protocol here: https://swim.dev/concepts/warp/

Learn More

Swim is an Open Source platform for building distributed real-time applications. For technical resources, you can find out more about Swim here.

Topics:Stateful ApplicationsSWIM SoftwareEdge AnalyticsSWIM AIEdge Computingdistributed computingHTTPweb applicationsswimOSRESTWARPstreaming