Skip to main content

TN9001: Project Model

Abstract​

To help developers and content creators manage their applications properly, we built a three-level model. This model can ease the mental burden of maintaining your resources, creating enough flexibility for the different deploying targets.

Developers can choose technology stacks at different levels of complexity to solve different tasks. In this article, we will give a brief introduction to this three-level model.

Introduction​

Recative System manages its content with a three-level model:

  • Asset: Asset is the minimum unit of independent content, it could be a piece of video, or a small piece of web application based on PIXI.js. You can expect there would be more possible options in the future.

  • Episode: Episode is the minimum unit of data loading, resource management, and lifecycle management. while an episode is initializing, we will try to download an asset definition list and preload all resources if the resource definition is required. If your environment implemented a cache method, the episode manager will also try to download the resource to the local hard disk, which will boost the initialize speed for further visits.

  • Series: If your content is too complex to be handled in one single episode, you can split your assets into different episodes, and add all episodes into one single series. The series manager will manage the lifecycle of every single episode. Since loading a new episode needs fetching additional data, performance may be compromised, please make a good trade-off between high RAM usage and extended load times.

For the different levels of abstraction, we have different packages to take care of lifecycles, RAM consumption, and performance issue.

  • ap-core: @recative/ap-core is a set of toolkits for building simple interactive content, we implemented multiple scheduling mechanisms to help developers building a web application without performance issues. Currently, there's official support for PIXI.js, Yoga Layout, anime.js, the support for three.js and Tone.js is under construction.
caution

Although our customers have built quite a few content products using ap-core, the API design has not yet reached the level of public availability. We are trying to disassemble @recative/ap-core into multiple smaller packages, to reduce the complexity of the whole solution.

  • Act Player: @recative/act-player is a React component which can render a lot of assets. EpisodeCore of @recative/core-manager can take care of the task of lifecycle management and RAM management. The implementation of the core manager is "UI-frame neutral", it is useful if your team is not using React or want to build a different product based on the existing system. The interface of this player is full-customizable, you can pass your own implementation of every single component. Read the following articles for more details about how to customize it.

  • SDK: @recative/client-sdk is a React component for managing multiple episodes, client sdk will take care of data fetching and life cycle management, and interface customize. If you are building a product that has multiple episodes, SDK could be helpful. SDK also supports interface customize, by building an interface component - an ESM module that exports a React hook - you can customize all possible behavior and visual experience with this feature without hacking the source code of act player.

  • Shell: Shell is the environment your application or program running in, it could be a website, a desktop client, or a mobile application. There could be different kinds of platform-specific capabilities, like in-app purchases, resource cache, sharing, or deep-link. We're trying our best to build a set of official shell implementations for most use cases. For users without special requirements, we encourage you to use the official shell implementation, which is better integrated into Recative Studio's workflow. If you want to customize the capability of shells, please fork our official implementation. We will introduce how the Shell interacts with Recative Studio in the following article.

tip

It's not necessary to fork the shell implementation if you only want to customize the visual experience of the player, consider building a "interface component" can greatly improve the maintainability of the project.

Use Cases​

Recative is a highly comprehensive system for interactive content management, developers can implement various web applications with different levels of architectures, here're some examples:

  • A naïve video player: Act player can be used as an independent video player with cross-browser consistent autoplay behavior and highly customizable API. Furthermore, if you want to build a web application with multiple videos, the multiple asset architecture would be useful if it belongs to single content and Client SDK can be used if they belong to multiple pages.

  • A naïve WebGL application: If you want to build a simple web application for all major platforms, including mobile and desktop platforms, ap-core could be a handy tool since it handled a lot of possible performance and compatibility issues, especially for Safari.

  • A complex web application with mixed forms of content: This is our main purpose of developing the Recative System, by using the whole solution you can get a series of simplified workflows from resource management, and preprocessing to project packaging and deployment.