Performance is a vital aspect of any API, even more so when it powers data-rich and omnichannel experiences, as in the case of video streaming platforms. Slow load times and latency are an instant turnoff to end-users. However, video streaming platforms rely on hefty data sources scattered across dozens of APIs and backend systems. Connecting these APIs to serve omnichannel platforms such as web, mobile, and desktop present a set of challenges.
Article
Performance-Driven APIs for Video Streaming Platforms
Connecting Frontend Clients With Backend Systems In Fewer Steps
One such complexity is over-fetching, where API requests gather more data than what is actually required. This is especially problematic with increased mobile usage, which requires efficient data loading. There is also the problem of under-fetching where a specific endpoint provides insufficient data. Multiple roundtrips have to be made to gather the required dataset to render a single screen. Such requests can quickly pile up and impact performance and slow down screen load time.
Super-Performing APIs With GraphQL
Performant APIs reduce bandwidth and improve the speed of serving data requests from frontend clients. GraphQL, an open-source query language for APIs and a runtime for executing those queries, has risen in popularity as means of addressing these complexities. It was designed to make API development faster and more flexible to manage changing client requirements.
GraphQL responds to the complexities described earlier by exposing a company’s full data graph as an endpoint. Using the endpoint, developers have granular control to fetch precisely the dataset that frontend clients require. This cuts the need for multiple roundtrips to an API to get all the data, boosting performance and saving bandwidth.
The most enticing factor about GraphQL to developers is its client-driven approach. The front-end client has complete control over dictating its data requirements. Also, GraphQL’s hierarchical structure allows multiple layers of data to be combined into a single query. Furthermore, GraphQL queries can be redesigned and modified during application development without the need for plumbing effort in the backend. This speeds up iterations and feature updates.
GraphQL’s universal schema and strong type system provide a more flexible and reliable communication structure to both front and back-end teams. With plenty of tools and self-documenting features that ease development efforts while providing the freedom to play around with the API.
GraphQL For Microservices
The rise in usage of microservices architecture has also propelled the adoption of GraphQL. Microservices split your business domains into modular and independent services that still need to communicate. Most microservice architectures require multiple requests to different microservices to serve a single client request. GraphQL reduces the need for multiple requests by combining all the possible data that a microservice exposes into a graph.
Furthermore, you can combine graphs from multiple microservices with a federation service such as Apollo Federation. These microservices can still be developed independently, while their respective subgraphs can be integrated and addressed through a unified supergraph. Clients can query data from multiple microservices via a single query to the supergraph. The unified graph separates the main query into subqueries to retrieve data from the respective microservices. Apollo federation requires no central development/schema stitching. When a service adds a new field to its graph, it will also be available in the supergraph.
Further benefits that this unified approach brings include:
-
Hides backend system complexities behind a unified API.
-
The single API integrates with any programming language used by front-end applications.
-
Apollo federation reduces the number of client requests to a microservice by combining requests from multiple parts in a query into a single request.
-
Supports the migration from a monolithic backend to a microservices architecture.
Video Streaming Use-Case
Let’s imagine we need to render a movie page of an OTT platform, and there are three backend services that provide the required data.
-
Catalog Service - Feeds the metadata of the movie.
-
User Service - Holds information about a particular user.
-
Recommendation Service - Provides a list of related movie recommendations.
The traditional procedure is to develop a UI that retrieves data from the backend services through 3 separate API endpoints. However, using GraphQL and Apollo Federation, we can combine the three separate APIs into a single endpoint that our client application talks to. The client can make a single GraphQL API request to retrieve all the data needed to populate the movie page, containing movie metadata, user information, and related movie recommendations.
A significant benefit here is that the recommendations service will know the best items for a user with just the item type and IDs. The metadata for the single items will come again from the catalog service. So the recommendation service keeps only what it must - which movies (IDs) are recommended for a user that opens a specific movie page. It doesn’t need to hold and synchronize the metadata for those items on its own. And it will not have to manually reach out to the catalog service to retrieve those values to answer its requests.
Future of GraphQL
As the demand for high-end streaming experiences grows, developer tools that streamline those experiences will shape the next decade. Developers will favor technology that makes their lives easier than established alternatives. GraphQL is an attractive proposition that minimizes the overhead on your backend systems. It enables performant and well-articulated APIs to support developers in keeping up with the fast-paced streaming industry.
