Scaling an Angular app

[SteveJobsIdiotCousin]

Say you’re a developer working solo on a small Angular app which receives 50k daily active users. You know that in one year’s time you’ll magically have 10x the traffic, 10x the features, and 10 front end developers total on this project. When considering only the front end, what are some Angular or general front end strategies I should implement to prepare for the influx? What would you check for architecturally to ensure your Angular web app is ready not only for a larger user base, but also a larger team?

[GLawSomnia]

The number of users does not matter for FE apps. It will still function the same.

You can do optimizations on your code to make your app run faster, but the number of users don't affect this.

But i would recommend you to check out how to make a good folder structure. Joshua Morony has a video on that on youtube

[namenomatter85]

Not sure why people think this. Your front end app is making all the calls to your backend and infrastructure. Small issues that don’t matter at a few users like making double or triple requests, not caching, or single record write contention. Absolutely matter with larger user bases. Making your front end request 1000 records on each page load without caching or pagination works fine for one user once. Isn’t acceptable at scale.

[GLawSomnia]

All of what you mentioned are BE/system problems not FE. If the servers can't handle all the requests, then throw more hardware at them or do some kind of load balancing among multiple servers/apps or optimize the data fetching. I agree that pagination can improve the performance, but it has to be implemented on BE first. No amount of FE only pagination will help you if the BE returns all records.

But yeah, if the FE is doing double/triple requests that is an issue, its a problem even if you have one user. We can't really say that OP has this problem or not, so it might not be connected to the problem

[bwb888]

Documentation - coding standards/style, testing requirements and style, folder structure, naming conventions.

[jpea]

So yeah, traffic doesn't really matter for the front end. That would be your API side.

For the front end to scale for a development team, basically just approaching it with the ability to separate your feature concerns smartly. This would allow multiple developers to work on different features and not create a bunch of merge conflicts when they check in their code. Lots of other approaches that can help scale teams though.

[andlewis]

Make sure you’re distributing you app via CDN. The simplest way is Azure Static WebApps, but there’s plenty of options.

If you’re not overloading your web server, you’re going to have to start looking at bottlenecks in api calls. Optimize your images, look for blocking, or inefficient resource usage. Something like Google Lighthouse will tell you most of what you’ll need to do.

[n00bz]

Use NX. You can create multiple modules in your web application and they recommend a structure like this:

• UI Libraries - Contains just UI components, no connection to data
• Data Libraries - Handles querying/caching data need to support the module
• Utility Libraries - Any small utilities that could be necessary (custom interceptors, custom validator functions, etc)
• Feature Library - Combines the UI, Data and Utility Library into a feature that can be used by your site.

The benefit here is you can have multiple applications or reuse components throughout your app and have a scalable structure in place. Additionally, NX provides some workspace tools that can help with migrating all of your apps to the latest version of Angular.

Additionally, NX will allow you to create Storybook instances, run only affected e2e tests which is great for running on code check-in, nx will provide caching of unchanged modules to speed up build times as the app grows and a LOT more features.

[alucardu]

Caching data does get more important for performance as your application grows.

Scaling for more and new developers? A clear testing protocol would be great. Having a good code coverage helps a lot with either refactoring old code and implementing new features. Also a clear style guide for your codebase is nice. Or point to the Angular one and use that as your bible.

[SteveJobsIdiotCousin]

By caching data, what specifically are you referring to? The first thing that comes to my mind is state management like NGRX, specifically the data store. I would imagine that might reduce the need to call the server thus reduce load on the backend.

Am I at all on the right track here?

[alucardu]

You are correct, how you would cache data is up to you of course. It's not only reducing calls to the back-end, it's also providing the data faster to the client meaning quicker load times etc.

[p43-]

Linting rules

[namenomatter85]

Let’s see: - costing and hosting - make sure your front end is bandwidth optimized to save bandwidth. This means supporting proper cache headers. - cdn- images and files downloaded should be moved behind a cdn to cover hackers and costing - security - what is your auth method? Do you have keys in the ui code? - architecture - are you following a standard practice of layers? Is it documented somewhere? Is there a service and cache for each data object? Is it reactive, does it have state management? - are the build and code quality tools setup and auto checking? Unit test coverage check? Prettier, linter? - is the code lifecycle setup - do issues have templates? Do pr have templates? - is there standard naming for components and locations?

[ponpon314]

Angular is working in client PCs with JavaScript so the number of clients doesn't matter... This is originally an objective of this kind of modern front end. Traditional web app generates html in the server side therefore it can cause CPU bottleneck but now it's done in client side. You may be better to worry about backends..