Factors that affect the scalability of JavaScript applications

Introduction: JavaScript applications are becoming more and more large. This is because using JavaScript can do far more than most of us need. We cannot consider the extension of software systems just because they are technically feasible. Adding scalability to a system that does not need to be extended is not worth it, especially for end users, which makes the system more cumbersome.
This article is selected from the best Practice Guide for large JavaScript applications.

As a JavaScript developer and architect, you must recognize and understand the factors that affect extensibility. While not all JavaScript applications need to be extended, there is always a part of it that needs to be. For example, it is difficult to confirm that a system does not need to be expanded and that it does not need to spend time and effort on its extensibility. Unless we develop systems that do not require post-maintenance, there is always an expectation of growth and success.
On the other hand, JavaScript applications are not inherently mature extensible applications, but are incrementally accumulating and evolving into scalable applications. For JavaScript developers, the "impact of extensibility" is an effective tool. We don't want to be overly designed from the start, and we don't want to be tied up with early design, limiting scalability.

The need for scalability

Extension software is a response-based activity. Considering the impact of scalability can help us to be proactive in preparing. In systems such as the application backend, this "extended activity" is usually handled automatically and may be a brief peak of access. For example, a surge of user requests leads to a load surge, when the load Balancer intervenes and distributes the load evenly to the back-end server. In some extreme cases, the system may automatically prepare new backend resources to cope with changes when needed, and automatically destroy those resources when they are no longer needed.
But the front end is not the same, and the extended activity of the front end usually takes a long time and is more complex. The unique side of JavaScript is that the hardware resources available to the browser are all the hardware resources it can use, and the data it gets from the backend can grow proportionally, but that's not what we need to consider. As software evolves, we must focus on the "impact of scalability" in order to succeed in doing something.
650) this.width=650; "Src=" http://img.blog.csdn.net/20170220163316183?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvynjvywr2awv3mjawng==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "alt=" Picture description "title=" "style=" Border:0px;vertical-align:middle;margin:auto; "/>
The impact of scalability is demonstrated from top to bottom. First, the user proposed the software needs to realize the function, then the function size, and other functions of the relationship and other factors will directly affect the composition of the development team, along the top-down impact of the arrow to grow accordingly.

A growing user

If you're building an app that serves only one user, there's no need to be so much of a fuss. Applications built on the basis of a typical user's needs will serve a greater number of users. So in the process of application evolution, we should anticipate the growth of the users. Although there is no exact number of target users, based on the characteristics of the application itself, it is still possible to use http://www.alexa.com/as a benchmark to set the target value for the number of active users. For example, if our app is accessible to anyone, you will want to have a large number of registered users, but the number of users joining the system will grow more slowly if only for personal installation. But even so, we want the number of deployments to increase, to increase the amount of software users.
The number of users interacting with the front-end interface is the biggest contributor to scaling apps. Each additional user is accompanied by exponential growth at various architectural levels. If you look from top to bottom, the user decides everything. The existence of an application is ultimately intended to serve the user. The more easily the JavaScript code expands, the better it will delight the user.

Add new Features

Perhaps the ability to please the user is the most obvious companion to a large user base of successful software. The capabilities of the software continue to grow with the number of users, although the new features are obvious, but are often overlooked. Knowing that adding new features is inevitable, we rarely think about how to reasonably implement new requirements in code. It is the lack of such thinking that hinders our continued development.  
This is tricky in the early stages of software delivery. Software developers will do their best to attract new users, but due to the limited functionality of the initial phase to attract users, the results are minimal. There are not enough mature features, no large development team, and no chance to break user habits. When these restrictions are not available, it is easier to implement features that dazzle existing or potential users. But how can we force ourselves to think through early decisions? How can we ensure that our ability to extend our software is not limited by providing more functionality?  
You may find that whether you are developing new features or enhancing existing ones, it is always an issue to consider in the extensible JavaScript architecture. We need to consider not only the various features listed in the Software promotion copy, but also the complexity of these features, the commonality between each function, and how many "moving parts (movingparts)" Each function has. When a top-down look at the JavaScript architecture, if the user is the first level, then each function is the next level. Expanding from this level becomes complex.   The
complicates functionality, not a single user, but a group of users who need this functionality. From this perspective, we have to think about the characteristics or roles of the users who use the software and what roles are available to them. The need for such an organizational structure was not obvious at first. Until later, when our previous decision made it difficult to implement a character-based feature, it only appeared. And, it also depends on how our software is deployed, and sometimes we may need to support a number of different use cases. For example, several large institutional users may have their own deployment scenarios and are likely to have their own unique user structure constraints. This is challenging, and if you want to be scalable, the architecture needs to support the disparate needs of these organizational structures.

Hire more Developers

Implementing the various functions of the software requires a reliable JavaScript developer, and they should know what they are doing. It's a lucky thing to have a team of developers like that. Team building is not spontaneous, and there is a need to build trust and respect between the teams to some extent before they can develop good code. Once we start, we are in a good state. Take a look at the top-down extensibility factors mentioned earlier, and the features we're going to develop will have a direct impact on team health. The balance between the two is basically unsustainable, but it can be as close as possible. Lack of manpower but too much functionality to implement will put pressure on team members. When delivery is hopeless, people won't try. On the other hand, if there are too many developers and limited functionality to develop, there will be more communication burdens, and it is difficult to define responsibilities, so when there is no consensus on responsibility, it is not far from failure.
Rather than having too many developers, developers are less prone to developing features. When faced with the enormous pressure of functional development, it is a good time to step back and think: "If we have more developers, what will be different now?" "This problem is often overlooked and goes directly to recruiting more developers. And to everyone's surprise, the ability to recruit new recruits has no immediate effect. That's why we need a culture of research and development that has no stupid problems and a clear responsibility.
The team organization structure and development method are not fixed, the development team needs to deal with the development of the situation, the biggest problem is undoubtedly the number, size and complexity of the function. So these are the first things we need to think about when we build our team and how we grow. The latter point is especially important, since the initial team structure is not adaptable when there is a significant increase in functionality.
As these scaling factors change over time, we adapt the design or modify the product to meet the challenges of scaling with an architectural perspective.
To further discuss these factors that affect the extension, learn more about them and prepare a checklist to help us implement scalable JavaScript applications to respond to these events, as seen in the book "Best Practice Guide for large JavaScript applications".
This article is selected from the large JavaScript application Best Practices Guide, which can be viewed on the blog's website.
650) this.width=650; "Src=" http://img.blog.csdn.net/20170220162913884?watermark/2/text/ ahr0cdovl2jsb2cuy3nkbi5uzxqvynjvywr2awv3mjawng==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/ Gravity/southeast "alt=" Picture description "title=" "style=" Border:0px;vertical-align:middle;margin:auto; "/>

want to get more wonderful articles in time, search for "blog view" or scan the QR code below and follow.
650) this.width=650; "src=" http://img.blog.csdn.net/20161128135240324 "alt=" Picture description "title=" Picture description " Style= "Border:0px;vertical-align:middle;"/>

This article is from the blog of "Blog View blog", make sure to keep this source http://bvbroadview.blog.51cto.com/3227029/1899541

Factors that affect the scalability of JavaScript applications