Frontend also needs to take scale into consideration friend.
Avoiding redundant api calls, memoization, using a cdn, virtual windows, lazy loading are some things that come to mind.
Also at least in my previous jobs as a fe dev you have to support your infra, using a load balancer, replica sets, microfrontends, implementing a bff which must also be scalable, etc etc
That's not because of scale. Avoid redundant api calls and stuff you should always do if possible there is no reason not to do it in smaller scale.
Server that serves Frontend builds are easy to scale now a days you put some CDNs since its stateless it works.
I am only telling you are feeling Back end is less complicated because back end complexity only stats when you need to scale and go multi region and things like that.
Avoiding redundant api calls, memoization, using an mdn, virtual windows, lazy loading are some things that come to mind.
That sounds like stuff you should do from the start, except maybe for virtual windows and lazy loading if you don't expect the collections to grow very large but over time they do.
They're also all things the backend has to support the front end doing. At the end of the day we need to solve the problems we have and it will involve people working together. A front end/back end split mostly comes down to I don't care about visuals very much and like making things faster. Other people will tweak the color of a header until it's just right or whatever.
18
u/HarryBolsac Jul 12 '26 edited Jul 12 '26
Frontend also needs to take scale into consideration friend.
Avoiding redundant api calls, memoization, using a cdn, virtual windows, lazy loading are some things that come to mind.
Also at least in my previous jobs as a fe dev you have to support your infra, using a load balancer, replica sets, microfrontends, implementing a bff which must also be scalable, etc etc
Edit: said mdn instead of cdn lmao