What are the most effective techniques for scaling front-end applications?
There is a subtlety with this question. The traditional definition of “scalability” applies to computer systems and their ability to gracefully handle large concurrent loads across a set of computers. A front-end application runs in a browser on a single machine, which is not a set of computers – we don’t care (much) about load on a single machine.
Typically, when the term “scalability” is used, it is used in the context of computer systems, but we can also refer to “scalability” for front-end applications in their ability to scale complexity. That is, “scalability” for front-end applications means scaling the project to have many developers working on it productively rather than adapting it to handle high concurrent loads.
Scalability vs. Performance. Scalability (for systems) and performance are related but separate concepts. “Performance” applies to a single unit of work or session. Front end developers are keenly concerned about performance, of course, but “system” scalability concerns simply don’t apply to a browser application.
Front End Apps Small and Informal. Most front-end applications have tended to be small and informal affairs – at least compared to their back-end counterparts. The problem is that the best approach to developing a small application is typically not the best approach to developing applications with thousands of files and 25 developers working together with multiple teams.
Do It Like Back End Developers. Back-end developers have long been accustomed to working in large groups to develop a complex application. Back-end developers use modularization, composition, architecture, testing, and tooling to support large-scale application development. There is a little more to it, but following these five guidelines will cover most of your project scaling needs.
Composition. Composition is closely related to modularity. It simply refers to a way to combine simple objects into more complex ones. Composition is not helpful for small data sets, but as the data sets get bigger, the data becomes much easier to understand when composed. For example, if you have very simple data about a person, including their phone number and address in a “person” data set makes sense. When you start including other data such as different types of addresses, things are easier to understand when the data set is composed. When things are easier to understand, they are easier to share. In fact, even for a single developer working on a project, you will be happy that you composed objects from simpler objects if you have to maintain the code several months after writing it.
Architecture. While it is generally understood that architecture – planning the technology before implementing it – is a great idea, many projects simply don’t do it. This is OK for small projects, but as projects scale larger, the penalties for failure to plan tend to increase exponentially.
Automated Testing. When you are working on large projects and some code breaks, it is often unclear who broke the code. This is especially true if you are developing with a lot of modularity and composition because a code layer that someone else wrote could have broken yours. Automated tests help ensure that breaking changes are caught quickly.
Tooling. Appropriate choices of tools can contribute quite a bit to scaling on a project. Leveraging full frameworks rather than libraries, continuous integration, clean build, logging, and monitoring contribute substantially.