A collection of the most important components of the Waasabi suite.
The repository for the
waasabi tool on npm, the configuration CLI (commandline interface) of the Waasabi suite. It allows for easy bootstrapping, full customization and deployment of Waasabi instances using the
npx waasabi shorthand command.
waasabi-init tool generates a configuration file that is executed in the target environment by the
At the core of Waasabi is an administration interface and a powerful backend API provided by Strapi that implements the core features and acts as an intermediary (and chief source-of-truth) between the various cooperating components the instance is composed of.
Upon instance creation a brand new Strapi service is configured and launched from scratch, customizing the new instance with pre-existing endpoints and the
event-manager plugin (that is not currently available separately, only as a part of this starter kit).
The new service takes care of providing an administration interface for furter configuration of the instance, management of the instance-provided content (such as events and schedule), managing streaming providers, scheduling and configuring live streams and serving the real-time API for the Waasabi Live frontend/live experience webapp.
Strapi, in it current version does not natively support exposing lifecycle events as GraphQL Subscriptions natively. An important feature and service that Waasabi’s backend provides is aggregating incoming information from various sources and making it available through a GraphQL API in real-time using Web Sockets to the frontend application.
The above is currently accomplished by providing a custom version of Strapi’s built-in GraphQL plugin that replaces the native plugin with one with rudimentary GraphQL Subscriptions support. This provides a Web Sockets-based real-time GraphQL API for the
signals endpoint of
events-manager which then is able to signal the frontend clients
It is planned to replace this solution in the future with a purpose-built Rust service that exposes new events in
signals using built-in support for PostgreSQL
NOTIFY and a very focused, minimal GraphQL-subscriptions-over-Web-Sockets service implementation.
This change is expected to:
- improve the performance of the signaling system
- allow for better sharding and load-balancing for high-traffic scenarios, with a stateless service and a central database source
- allow better metrics and health reporting for this crucial part of the Waasabi architecture (number of connected clients, message latency etc.)
This is the built-in event streaming page of Waasabi. In theory Waasabi supports embedding into any existing website, using practically any frontend build system or framework. The
waasabi-live repository has two primary intentions:
- to provide an out-of-the-box event streaming experience for those who are not interested in building or customizing their own
- to be a project feature showcase and serve as experimentation grounds for features and UX considerations of online events – many of which we talked about in detail at the project’s outset.
Even for those who decide not to integrate tightly the Waasabi suite deeply into an existing system, and instead use the provided
waasabi-live experience this repository offers a very comprehensive branding functionality. This allows for a branding (“theming”) package to be provided at instance creation time that will override various portions of the baseline experience and is able to:
- provide custom images, fonts and other assets
- change and modify the page styling and colors through additions to the CSS configuration
- override default page structure and content
Many aspects of the Waasabi Live page experience can be configured during initial setup and from the administration interface later, but the above options allow for virtually unlimited customization options without the need to fork or change the built-in files of the Live interface.
The live experience builds from these source files through a build step that generates the final deployment artifacts in a form of a Single-Page Web Application (SPA). Given that the Live experience is focusing on providing an uninterrupted video live streaming experience, the SPA nature of the frontend and avoiding page navigations seemed an important goal and acceptable tradeoff.
apollo-client GraphQL library used as a Subscriptions client for the incoming real-time signals. That said, it is under constant evaluation whether these (and other) dependencies can be avoided, or replaced, without detrimentally affecting the end user experience and thus removing some of the page weight.
Beyond the core components of the Waasabi suite listed above, there are several add-on modules already available (and integrated into the Waasabi instance configurator) that allow interfacing with other systems, making them an integral part of the Waasabi experience.
One of the stated goals of the Waasabi suite is to provide unprecedented flexibility and a strong core experience to integrate various systems into an experience that the organizers/hosts of the Waasabi-serviced events have full control over. A major component of this strategy is to provide easily pluggable and configurable integrations to popular services, lowering the amount of components that need to be built for more fully-fledged and complex experiences.
The Waasabi suite plans to provide out-of-the-box integrations for various real time chat services to allow event organizers to bring their existing communities safely into their virtual event platform. The
waasabi-matrix integration allows for tightly integrating the open source Matrix messaging platform with the Waasabi experience.
This integration goes beyond simply ferrying messages back-and-forth between Waasabi and the chat platform but comes with advanced features of moderation, private rooms and access control and allowing for the creation of community-owned rooms that can be exposed, organized and joined from the Waasabi live interface with ease. This allows for conversation to organically split into smaller groups without compromising the safety of the event, and opens nigh limitless possibilities towards interactivity when utilizing the two-way integration provided by the
waasabi-matrix bot between the two systems.
The integration is the first component of the Waasabi suite that’s written entirely in the Rust programming language as an external service, and as such is reasonably self-contained, and can be used as a baseline for creating Matrix service bots for other usecases, or modified for specific usecases in custom Waasabi instances.
Complementing the commercial live streaming backends offered by the early versions of the Waasabi suite, the Waasabi Peertube integration is the first (in many) alternate video streaming providers that is entirely open source and self hosted on the Waasabi instance itself. This means that small events are now able to create an entirely self-contained experience with no external service dependencies and host events completely on their own terms without needing to rely (or share data) with external third parties.
Being a fully functional instance of the Peertube network, this video streaming backend option also provides access to a wide range of federated instances through the ActivityPub protocol, providing extra reach and community-federation and replication of recordings of the event to alleviate the resource pressure on the hosting server.
Provided as a separate component, the
peertube-plugin-waasabi component is installed and configured automatically by the
waasabi-init instance configuration tool whenever a new instance is created from scratch with built-in Peertube backend support, but can also be added through the Peertube plugin store to existing instances, and manually updating the Waasabi instance configuration to take advantage of the new backend.
Note: this document partially supersedes the Waasabi Project Architecture document published earlier as it represents a later step in the project’s evolution. That said, the original document has relevancy for historical and project direction/ideation documentation purposes and thus will be preserved until this two documents can be consolidated a single cohesive document.