Content as a Service facilitates the creation and distribution of digital content over multiple applications by centralizing data into a single asset management system. The Content API is the primary service editorial and audience application developers interact with. Providers are programs or scripts that are developed to facilitate interaction between a Content Source (such as an editorial application or CaaS itself) and the Content API, transforming the data into appropriate form for storage. Projectors function similarly to Providers, but in reverse: the Projector reads entity objects from the Content API and transforms or formats the data for broadcast to their respective Audience Applications. Projectors can also use the Content API to search for specific entity data.
What should be stored via CaaS? CaaS is not a database for storing application data that would otherwise be best served by MySQL, for example. The Content API is not intended to support audience requests, or other real-time high-volume requests. CaaS is for cross-brand Time content—as a rule of thumb, CaaS is for anything that can be used by multiple brands or multiple distribution channels. Another way to think of this is that CaaS is a way to store, relate, transform, and retrieve things relevant to systems other than your own.
Check out the Content API Documentation with example code, or learn more about the General Concepts and Components of Content as a Service, below.
General Concepts
Content as a Service is the technology providing content from any Time Inc. source for any possible end or business case, referred to generally as audience applications. This content can come from any source and be in any digitizable form, from People Magazine articles to Sport Illustrated photographs to content stored in CaaS itself. Audience applications can be anything from Time articles served as Google AMP pages, the Assignment Desk application, or your own CMS. Content as a Service—the combination of tools, services, protocols providing content across the entire Time Inc. ecosystem—is also referred to as CaaS.
Content as a Service is not a traditional database management system. That said, we refer to the place where data is stored as the Content Service. The Content Service is technically comprised of several parts, including S3, Dynamo, and Elasticsearch, all architected to work together to serve the needs of Content as a Service, but you will never interact with them directly—CaaS’s Content API handles all that for you.
The Content Graph is a way of looking at the data as a highly performant set of relationships. Of course a traditional DBs can handle relationships, but they do so in an inefficient way requiring a lot of overhead. In the Content Graph, you can give your document any number of edges with any names and—it just works.
An Entity is any data object stored in the Content Service as a JSON document and thereby functioning in the Content Graph. In addition to specifying at least one Provider, a type, and a name in your JSON document, you can include whatever you want. Of special interest is the ability to include edges: data elements that refer to other entities.
Components
A Content Source is any source for digitizable content. The brand CMS is the most common and obvious source for content, but content can be ingested from an extremely wide range of sources, including user input data as in the case of the Assignment Desk application currently in use by over a dozen brands, the Recipe Desk application, and the in-development DCP application.
An Audience Application is any application of Time Inc. content for any business purpose. Google AMP, Apple News Feed, and Facebook Instant Article are examples of audience applications currently in production serving Time Inc. brand content to millions of users. The variety of applications is unlimited—you can develop new applications quickly to meet any new business case and the content will already be available in the CaaS Content Service for projection into the new application.
A Provider is an application or script that takes content from the content source and transforms it into a suitable format and stores it in the Content Service. Providers can be written in the language of your choice (best though to use one that has an AWS client). Providers use the RESTful Content API in a process often referred to as ingestion: the process of getting content from a source such as a CMS into the Content Service for use by CaaS. Typically you’ll interact with the Content Service using a message-driven paradigm, by subscribing to an SNS topic for example.
A Projector is an application or script that takes content from the Content Service and serves it transformed for a specific audience application. You decide on the experience you want your audience to have and build it using data from Content as a Service. Projectors can be written in the language of your choice (best though to use one that has an AWS client). Projectors use the RESTful Content API. The typical manner for interacting with the Content Store is by way of a message-driven paradigm, by subscribing to an SNS topic for example.
API Documentation
For working with the Content API and the CaaS Content Client, please take a look at our Content API Documentation.
