Scalability for Storybook

In this post, we will discuss the notion of scalability concerning the StoryBook project. As scalability is an aspect where software architecture plays a particularly important role, this had to be analyzed in our series of posts about the project.

Scalability challenges

Fortunately for the Storybook project, most known scalability challenges do not apply to it. Examples of these challenges are database scaling and insufficient caching ¹. Storybook is used locally on the machine of the developer, where each developer has his own copy of Storybook as a node module dependency. This means that Storybook is inherently centralized for each user that installs the package.

Being a single package, Storybook does not have to deal with scalability patterns such as Scatter/Gather or Master/Architecture ². Moreover, it does not have to deal with multiple users at runtime (for distribution this is different, but this is taken care of by the NPM registry). Workload and load balancing also do not apply as scalability challenges ³.

What could be a scalability issue for Storybook, is the amount of component dependencies. Storybook builds upon several other packages such as Babel, TypeScript, and webpack. Storybook uses node modules as the architectural pattern for managing their dependencies. This is mainly done in the package.json file ⁴ where the dependencies are listed and the required versions (or even range of versions) are specified. This facilitates scalability as the NPM registry will provide the packages needed and Storybook does not have to keep track or worry about having or distributing the correct dependencies. This allows for flexibility as the system’s components are loosely coupled and can be reconfigured at any time. However, when working with multiple add-ons or non-trivial frameworks Storybook can face the issue of conflicting dependency requirements. The developers of Storybook are aware of this and this is on the current roadmap ⁵.

Nevertheless, there are a couple of key scalability challenges certainly applicable to the project. As the tool is often used for projects that could be maintained by a large team of developers, it can be difficult to work together using Storybook. Storybook is a separate interface and although collaboration is certainly possible using Git, the Storybook interface and personal workflow make collaborative development more difficult. Furthermore, when having a large amount of stories with multiple states, having a clear overview of all components is difficult. Components can become complex with a large number of states and arguments. Although this is inherently an issue for projects getting more complex and bigger, Storybook is affected by this as this pollutes the developer UI of Storybook.

Scalability Analysis

There exists a variety of scaling dimensions, such as the number of clients, input size, state size, etc. Each of these dimensions can be analyzed to find the bottlenecks of a system’s scalability potential. As Storybook is a dependency, where the dependency management is handled by NPM, many of these scaling dimensions do not apply to the project.

For our analysis, we decided to analyze the startup time for the Storybook interface, given a certain project. Performance is key for scalability ¹, and we experienced that this loading time degrades the usability for UI developers.

For our analysis, we have compared two projects which made use of Storybook to develop components. We measured the time difference for the Storybook interface to initialize between both these projects, see Table 1.

Table 1: Startup time

Furthermore, we tested adding add-ons to the starter project to analyze whether this affects the loading time. It is common that when a Storybook project grows, more add-ons are added. We measured the time difference with regards to initialization duration for the basic React application given the number of add-ons, see Table 2. As a side note, these are the most used Storybook add-ons ⁸.

Table 2: Startup times with addons

As can be observed, we noticed that Storybook scales quite well with adding plugins. However, component size does influence the loading time quite substantially. Notwithstanding, the Storybook contributors are aware of this fact, and they are working on it ¹².

Architectural decisions for scalability

Naturally, scalability is an important aspect of development. To make an application scale well, many architectural decisions must be made throughout the development of the project. In this section, we will discuss these decisions, as well as some recent changes to the architecture of Storybook that will improve their scalability. Finally, we will discuss some parts of Storybook that could still benefit from improvements.

Let’s start with some of the decisions that truly define Storybook as a scalable product.

Addons

One of the key features of Storybook is its extendability through its capability to plugin addons for extra features. These addons can do many interesting things, ranging from dark mode to source code generation. By separating these addons from the main project, Storybook can focus on developing only core functionalities. On the development side, this allows Storybook to scale, without adding a lot of dead weight in dependency sizes to the user’s projects.

Separated framework code

Storybook supports, as of speaking, 8 different frameworks. All of these frameworks need their own framework-dependent code to function. However, a lot of code can also be shared between the frameworks. Therefore, Storybook has made sure to clearly define the core of the project, which is shared amongst all the framework-specific projects. This, again, reduces dead code and code duplication in the user’s projects.

Code Splitting

We also need to talk about the major overhaul that Storybook introduced in the past year to one of its most important bottlenecks: bundling and building the stories and components.

Previously, the way Storybook went about this process was simple: Just build and bundle all stories, components, and their dependencies into one big bundle, as depicted in Figure 1.

Figure 1: How stories and components were bundled previously

But when it comes to the performance of bundling and building, smaller equals better¹³. Minimizing large bundles is called code splitting. The primary purpose of introducing code splitting is to improve the performance of your Storybook. That is, the time it takes to install and startup and how long it takes to download and interact with a built Storybook.

Because of this, the team behind Storybook focused on enabling code splitting in Storybook for version 6.4 of Storybook¹⁴. The immediate impact is smaller bundle sizes, which means that built Storybooks should load up faster. This allows for larger Storybooks without losing performance. We can see the resulting bundles when building with these changes in Figure 2.

Figure 2: How stories and components are bundled with StoryStore V7

After these changes, Storybook has seen both build sizes and times to render the first story improve drastically, as can be seen in Table 2.

Chromatic Benchmark Results	Spotify Benchmark Results

Table 3: Results from benchmarks with the new changes¹⁵.

There is a major caveat to the change mentioned above: The bundles are still loaded at the same time.

Therefore, even if the bundles are faster to build as a whole, a lot of improvement can still be found, because not all bundles are needed at the start.

Our proposed optimizations

To build further on the performance changes that we mentioned above, and that was realized in 6.4¹⁴, we propose that Storybook makes use of a new feature that became available in Webpack 5: lazy compilation¹⁶.

This will allow Storybook to only generate the bundles required to render the stories currently visible on the screen. With this change, a storybook should be able to render much more quickly and be able to handle many more stories without also requiring much more memory and much longer build times.

Another feature of Webpack 5 that would work in tandem with lazy compilation is (file system) caching¹⁶. Using this feature, webpack would cache previous builds (or parts of it) and skip the no longer necessary steps when rebuilding, using this cache. This might come at a detriment to memory usage (either RAM or Disk), and therefore it requires experimentation to find a good trade-off.

In Figure 3 we have depicted the way Storybook would work with our changes. When a user requests to see the button story, the Story store would go ahead and only bundle that story file. After switching the screens, the Story store would then cache the previous story file, to reduce the following build-time when the user requests the SettingsScreen stories again.

Figure 3: Our proposed Storybook optimizations

Optimizations in practice

We will now conduct a brief empirical quantitative analysis to show how lazy compilation and file system caching reduce loading times. According to the blog written by the maintainers of the project, it should decrease the time by a factor of 3-5x. The difference in loading times between a simple React application using Storybook, and the larger MetaMask project, are displayed in Table 4.

Table 4: Loading times

As can be seen in Table 4, both the start time and the rebuild time are significantly improved by these optimization changes. We believe that these changes are essential in scaling and using StoryBook with larger projects.