Summary

There are three main areas of concern when it comes to scaling influencers in JavaScript applications. Each area influences the area directly beneath it, until we ultimately hit the ground floor, where development takes place.

First and foremost are the users of our software. There are a number of user-related factors that influence the need for our software to scale. For instance, the business model our organization chooses subtly affects later decisions about our architecture. License-based deployments are likely to be deployed on-premise somewhere, and therefore more likely to require customizations. The combinations of complexities are endless, and they all stem from the users of our software.

The next major area we looked at were the features themselves. We have to take much of the insight gained from thinking about our users and their influence on scale, and provide this as input to our feature design. For example, a lot may happen in a short period of time, once people start using our software. How will this distract us from the core value of our application? Believe it or not, focus is something that needs to scale too.

Finally, there are the development activities. There's the team to build, and finding the right people isn't easy. Even if we have a team of solid developers in place, the responsibilities, and how they are influenced by the features and the people using them, needs to be taken into consideration. Likewise, as the development of our application progresses, we have to ensure that the right resources are in place.

Now that we've laid the foundation of what scaling is all about in the front-end, we're ready to pe into the specifics. The remainder of this book will put the concepts of the first two chapters into a JavaScript context. We know what scaling influencers are, and now we get to make architectural trade-offs. This is the fun part, because we get to write code.