Will your Angular app smoothly scale to millions of users?

Here's a guide with 5 tips on how to build an Angular application that won't cave in and crash. 🔥 🔥 🔥

Need some tricks and tips you can use to punch up a large scale Angular application?

What are some good practices that you can use to make your Angular app will whiz along even under pressure?

Here's how to give it a few steroids.

1. Break a big Angular app into smaller Angular apps.

Consider the basic example of an eCommerce store. We have different moving pieces like...

• Storefront & Products
• Login & Register
• Checkout
• Administration Panel

You should consider separating each one of these pieces into it's own Angular app.

Why?

One benefit you'll receive is that if one of these apps goes down or has a serious bug, the others will remain unaffected. When engineered properly, it'll make it impossible for one app to crash your entire website.

This also gives you the benefit of making it easier to assign developers or teams specific responsibilities.

When you're building an Angular application at scale there are so many pieces to juggle. Yes buster! You've got all kinds of hairy things to look after like...

• 3rd party libraries and plugins.
• Design changes.
• Feature toggles.
• Changes to the web copy.
• Marketing tests.
• and then oodles more...

In summary, this type of model helps ensure that issues are contained. And makes it easy for better ownership and maintenance.

2. Use a headless CMS

Scalable Angular apps need to designed in a way that the marketing department can carry on with all their fancy web copy, image and other content without harrassing the development team. And the development team should be able to focus on what they do best without bugging the marketing team.

How you separate these responsibilites will vary but a good rule of thumb is that the marketing team be responsible for the images and copy. And the developers manage the presentation and design stuff.

This is where a Headless CMS is valuable. Enabling you to separate the presentation layer from the content layer. Developers can manage the presentation, design system, etc... while marketing has the full control of images and copy.

Another obvious benefit you will gain is that no new deployments will have to be made push the latest marketing changes.

This also gives you the ability to build multiple UI's with the same content data.

Last but not least you gain a performance benefit. You can deploy the marketing content to a global CDN where it is effectively cached and available everywhere and all the time.

3. How do you handle bugs at scale?

It begins by preventing bugs at scale. And making sure they never sneak through your QA department and slip out into the wild.

Prevent bugs

Knowing what to test and getting the best ROI is the first step in the right direction.

Not sure what parts of your Angular apps you should be testing? Check out this article.

Besides all the common and normal testing practices don't forget that your Angular application is being used across all kinds of devices, browsers and networks. You can't go wrong pressure testing from every angle.

A great tool for this is BrowserStack.

Track bugs

Often developers don't see what the live user sees. Or experiences what the live user experiences.

Building a client side error logger is worth considering. One example of this is monitoring HTTP calls for slowness and logging an error to a log server if it's taking too long. I've written an entire article about this here.

Monitoring

And last of all, you should be monitoring your Angular application to make sure it's rock solid. Dynatrace is a great monitoring tool for large Angular applications.

4. Feature Toggling

When done wrong, features kill scalability. But when done properly, they fuel scalability.

With millions or billions of users depending on your app releasing a shiny new feature to 100% with no kill switch to flick it off in case it's buggy is... well... dangerous.

• Launch new features with on and off features. That way the new features can be turned out if they're proven to be buggy. This can also be used for A/B testing for different markets.
• Track usage/behaviour by rolling out new features to 1-5% of new users. And then 5%-20%. And so on. Learn and improve before 100% rollout.

Check out this article for more details about feature toggling.

5. Consider using Bazel

A lot of small, medium and even many large Angular web application don't necessarily need Bazel.

So should you even consider using it?

Stephen Fluin in his NgConf talk onAngular Enterprise recommended that when your application grows to include more then 50 libraries and applications you need to give Bazel some eyeballs.

Bazel has some tremendous power that lets build a subset of your entire application which can make build times much faster. It does come with a steep learning curve and takes lots of configuration to make your builds fly, so consider the obvious trade offs before making the jump.

Conclusion

Yes buddy! These are the tricks and tips you can use to punch up a large scale Angular application that will whiz along even under pressure.

Questions or comments? Don't hesitate to reach out.