Why the Streaming Interface Now Changes Faster Than the App Itself

Streaming has reached past half the planet. 4.13 billion people in 2026, roughly 50% of the world's population, now use an over-the-top streaming service, and smart TVs have overtaken cable as the primary screen people stream on. Every one of those screens is an application running on a device the platform does not own or control. For most of mobile's history, changing what appeared on them, even a single row of titles, meant changing the app itself. That constraint quietly became the ceiling on how fast a streaming product could improve the surface its members use most.

Sreekanth Ramakrishnan is a Senior Software Engineer with more than a decade building large-scale personalization and distributed systems, and recent years of that work have gone into the backend platforms that decide what those screens show. He was selected to present at GraphQLConf 2026 on how the largest streaming services render constantly changing pages from the server rather than the client. His focus is the layer most viewers never think about: the system that composes a page before any device draws it.

The Release Train Was the Real Limit

Shipping a change to a mobile interface has never been instant. Apple reviews 90% of app submissions within 24 hours, but every platform keeps its own review queue, and even after approval a change reaches only the users who download the update. Multiply that across TV, phone, tablet, and web clients, each on its own release schedule, and a small layout idea turns into a multi-team coordination problem measured in weeks.

Ramakrishnan led the backend platform behind content discovery at a major global streaming service, where exactly this friction compounded. A discovery experiment that should have taken days could stall while engineering groups aligned releases across platforms and waited for installs to catch up. His answer was to stop treating the screen as something the app defines. Instead, the server would decide the structure and content of a page, and the client would become a renderer of instructions it received at request time.

"The release cycle had become the actual limit on how fast we could improve the screen people use to choose something to watch," Sreekanth Ramakrishnan says. "If a change to a row of titles depends on an app update, you are iterating at the speed of an app store, not at the speed of an idea."

Moving the Decision to the Server

The approach has a name in API circles: server-driven UI, increasingly built on GraphQL. More than 60% of enterprises are expected to run GraphQL in production by 2027, up from under 30% in 2024. The premise is that the server, not the installed app, owns what a screen contains, and the client holds only the knowledge of how to draw the pieces it is handed.

Ramakrishnan's platform organizes every discovery surface into a hierarchy of pages, sections, and entities: a generic data model a client can render without knowing in advance what it will receive. The same system feeds browse grids, search results, feeds, live titles, and games through a single contract. Because the structure travels with each response, a product team can change a page's composition through a backend deployment, and every client draws the new layout on its next request, with no rebuild and no store review in the path.

"A client should know how to draw a section, not which sections exist," Ramakrishnan explains. "Once you accept that, the screen stops being something you ship and becomes something you serve."

Reliability When a Single System Renders Everything

Centralizing that much control raises the cost of failure. When a single service composes the home screen for hundreds of millions of devices, an outage is not a degraded feature tucked in a corner of the app. It is a blank canvas in front of every member at once, and for a service of that reach, even brief unavailability outweighs most of what the team ships in a year.

So Ramakrishnan built the discovery API as one of the highest-criticality services in the platform, designed so that a single generic schema could serve every current and future surface while holding to the availability bar of infrastructure that is not allowed to go down. The architecture is recorded in a pending U.S. patent, with Ramakrishnan as a named inventor. He also engineered a parallel migration that ran the legacy stack and the new platform side by side, so production traffic at global scale never rode on a single hard cutover.

"A generic platform is only worth building if it is also the most reliable thing you run," Ramakrishnan notes. "The moment a single system renders every screen, correctness and availability stop being features. They are the product."

Letting Many Teams Build Into One Surface

The harder problem at this scale is organizational rather than technical. Large engineering organizations have spent the past few years standing up dedicated platform teams whose entire job is to let other groups move faster through shared infrastructure, because a platform that forces every change through a central group simply relocates the bottleneck instead of removing it.

Ramakrishnan designed a plugin model that lets independent teams working on advertising, commerce, live events, and games contribute content into discovery pages without routing each change through the core team, with schema contracts adopted by engineering groups across 3 separate organizations. The same instinct shows up away from his day job. As a judge for the Beta University AI Super Hackathon, he has evaluated how small teams ship working systems under tight constraints, which is a compressed version of the question any platform has to answer: how cheap can you make it for someone else to build well.

"A platform succeeds when other teams stop asking it for permission," Ramakrishnan observes. "If your central team sits in the path of every change, you have built a bottleneck with good documentation."

What Comes After the App-Release Era

The direction is set. More of the interface people touch every day is now decided on the server, across living-room TVs, phones, and the web alike, and the installed app is steadily becoming a thin, durable renderer rather than the place where the product lives. For many households the screen a server composes is already the main screen in the house.

Ramakrishnan is now extending the model so experimentation on these surfaces can run at the cadence of a backend test rather than a coordinated multi-platform release, and working on the less settled questions of how a single generic schema stays coherent as it absorbs new kinds of content. The aim is not to add more to the screen but to keep the system that decides it small enough to reason about.

"We spent a decade treating the screen as something that lived inside the app," Ramakrishnan reflects. "The work now is finishing the move to where it can actually change, and making sure that as one system takes over more of what people see, anyone on the team can still open it up and understand exactly why it shows what it shows."