Chapter 2. Influencers of Scale

Influencers of scale start with the users of our software. They're the number one influencer because they're the reason we've set out to build an application. As we saw in the preceding chapter, users influence features that ultimately influence the code we write and the development personnel who implement it. When we pause and think about these scaling influencers, we recognize that a sound JavaScript architecture that can handle them is a prudent cause. We can then take our findings and look at our code from different architectural perspectives. We'll dig into each of these perspectives throughout this book, starting with the next chapter.

But before we do that, let's go into more detail on these influencers of scale. We want to pay close attention to these because with every decision we make about our design, how it actually scales depends largely on the influences we've anticipated. Perhaps more importantly, we need to design our architecture in such a way that it enables us to handle scaling scenarios we haven't anticipated.

We'll start with a closer look at the users of our software. Why are they using it? How does our software make them happy? What's in it for us? These questions, believe it or not, are pertinent to the way we write our JavaScript. From users, we then move down to features, the outward-facing personality of our application. Some features aren't a good fit for our application, but sometimes that doesn't matter—we don't have a say. If we're going to scale up, to please our users, sometimes we have to make the best of these features.

The development resources, ultimately responsible for implementing these features, are a scaling influencer that can make or break a product. We'll look at the challenges faced by the development team, and how they're constrained by the feature influences. We'll close the chapter with a generic checklist for each of these influencers; to help ensure we've thought of the most pressing issues concerning our ability to scale.