Case Study: GraphCMS and Telenor

When you work with a monolith, you become a spec writer. We needed the abstraction layer and UI on top of it (database), which would have used a large amount of development resources.

Lars-Flemming ClausenSenior Engineer at Telenor

2k
New videos programmatically added per month
100ms
Max latency on millions of monthly API calls

About Telenor

Telenor (TEL.OL) is a Norwegian multinational TelCo which is one of the largest mobile telecommunications companies in the world. Founded in 1855 as a state-owned telegraph services provider, Telenor is now a significant global player in a full range of telecommunications. With operations across the Nordics and Asia with 182 million global customers and annual sales of around USD 12 billion. A leading Nordic provider of mobile, broadband, and TV services, the Telenor Group is 19,000 people strong. In addition to their Nordic operations, Telenor has many subsidiaries and joint ventures ranging from mobile financial services to online classifieds in the Asian region.

The Telenor TV distribution was founded in 1997 as a joint venture between French TV company Canal+ and Telenor called Canal Digital. Since 2003, Telenor has gained full ownership of Canal Digital. Canal Digital began as a direct broadcast satellite service but has since started offering cable television as well.

The Project

In 2013, Telenor created a video streaming service where users could stream content from several local television stations. The streaming platform for Telenor was previously a way for local television stations to make their content more accessible to a broader audience live on the platform for a longer time hosting adding around 2,000 videos/movies a month. As this was the first endeavor into a video streaming platform, there were many lessons to be learned.

The previous tech stack consisted of a common onboarding platform, which was a homebrew solution, that received content from the TV stations and then made the content available via the CDN. This tech stack, however, lacked a way to store and easily distribute metadata of video content in a central location. The lack of central storage and distribution of metadata meant that team members would manually edit metadata as needed, having to write new scripts every time there was a change. As the project grew, the necessary workarounds became more cumbersome and time-consuming, requiring significant manual work with limited ability to automate the processes with the tech stack was a priority. These manual workflows also lead to inconsistencies within the data set because of the decentralized file-based workflow. Data inconsistencies required the team to address these issues manually, further slowing down the process.

When the project received the green light to expand, it gave the team an opportunity to reevaluate the tech stack for the new project. There were several factors that were critical to choosing the new tech stack. Perhaps the most important being to remove this time consuming, manual process. The team needed to free up the development team’s time for more engaging tasks other than editing metadata. Centralizing the data and simplifying the process would also make it easier for the team to enact changes quickly. Another significant aim was to reduce the likelihood of incorrect information by creating a structure and organization to the centralized metadata hub so that the team could quickly adapt the information without a hassle.

The Evaluation Process

It was clear that the team needed a powerful database solution to achieve flexible content modeling and metadata aggregation. With the Telenor team being nearly 100 people with a mixture of technical and commercial users, the solution needed the feature-heavy nature of a highly technical solution and a clean UI to make it easy for team members to work with the data.

Initially, the team evaluated both monolith and headless systems. It quickly became clear that a monolith system would not be conducive to a more agile development process where teams could quickly get the first iteration of the tech stack off the ground. This iterative process was important for the Telenor team. With many of the monolith vendors, the initial project setup takes at least six months. To change a single field in a model, it may take two months to write custom plugins. With GraphCMS it can take seconds to change a field, and teams are able to have an initial structure in days rather than months.

When evaluating the monolith systems, it quickly became difficult to justify the high price tag for longer development times, a high degree of vendor lock-in and technical limitations of being dependent on a specific vendor.

“When you work with a monolith, you become a spec writer. Basically, for each new requirement, you write extensive documentation and hand it over. The vendor then builds something that might miss the point. So, you have to be a good writer and there is a risk that the newly added tech is not resolving the initial issue”

Lars-Flemming Clausen, Senior Engineer, Telenor

Taking the SaaS approach was more conducive to the working styles of the Telenor team. In reducing the overhead, the team was able to focus on features and workflows which were important to the project, rather than having to work around irrelevant features. Because the streaming platform is constantly evolving, as the Telenor team has a continuous delivery model, GraphCMS enables the team to work with agility. The Telenor team needed the scale of a database and ultimately chose GraphCMS to provide the same power with an abstraction layer for content, native localization, and schema builder. With GraphCMS, teams are able to programmatically feed content from multiple sources into GraphCMS which simplifies the work for content editors.

The flexibility that GraphCMS provides to set up and change the project schema as the project grows and develops makes the development of the projects faster and less of a hassle for developers to make changes later on in the development process. The clean UI and roles make it easier for content teams, in addition to developers, to add, fix, and change data points manually.

The Advantages of moving to GraphCMS

It was a key priority for the Telenor team to choose a modern tech stack that optimized for speed and standardized documentation. Implementing a GraphQL API quickly became a priority for this reason. The performance benefits as well as the impressive ecosystem of external consultants who can aid in development was also important. GraphCMS specifically offers API write mutations as well which allows teams to write directly in the database programmatically, eliminating manual work. Teams are able to direct content from multiple sources through GraphCMS programmatically which simplifies workflows and creates a centralized hub of data.

GraphCMS is native in GraphQL and supports the broad range of its functionalities. Because the API is GraphQL native, rather than being built on top of a REST API, GraphCMS realizes the performance benefits that GraphQL promises. GraphCMS strikes the balance of a modern tech stack without sacrificing robust feature set and reliability. The GraphCMS API is able to support the sustained high performance necessary for Telenor’s project of approximately 100 messages per second.

The team had previous experience with other database options and had worked with them extensively in the past; however, the lack of a simple UI and abstraction layer made it unfeasible. As Lars explains,

“we needed the abstraction layer and UI on top of it, which would have used a large amount of development resources, which we don’t have easily on hand in-house.”

The GraphCMS UI solved this problem with both a clean, simple interface and the inclusion of a no-code editor.

GraphCMS now provides the metadata through a database in order to create a centralized metadata hub. In addition to being more structured and organized than the previous collection of XML files, GraphCMS has significantly improved the workflows surrounding the metadata. The manual work that still remains is significantly more efficient with GraphCMS. Minor changes are now quick fixes done through the GraphCMS UI. For larger changes, the GraphQL API is leveraged to quickly make mass changes. The flexibility provided by GraphCMS allows the team to work quickly and create a first iteration of the project in just three months, a significantly faster timeline than competitors or a homebrew solution can offer. As the project continues to grow and evolve, Telenor is aided by the flexibility and power of GraphCMS to keep their project on time and high performing.

Why GraphCMS:

• Full GraphQL Native support, including a powerful API and ecosystem support

• API meets performance needs of less than 100ms latency on millions of API calls, making it significantly faster than other commercial GraphQL APIs on the market

• High degree of flexibility with the tech stack

• GraphCMS enables a quick time to market

• Sleek UI, which makes it easy to add quick fixes to the content

• No heavy licensing fees like that of monolith systems

• Fast feature development