7 ms·

Ask HN: Scaling the Front End?

2 points by 2bor-2n 5y ago

What are your strategies to scale up frontend? What process and coding style do you follow so that the project could scale up easily in the future?

johntdaly 5y ago
What is your definition of front end that it needs scaling? What is your setup that a proxy and CDNs aren’t enough scalability for a front end? I haven’t encountered a case where the front end is ever the scaling bottleneck so I have to assume that if it is in your case you either are doing something novel or you are defining something that is usually back end as front end.
- johntdaly 5y ago
  Dude, it is not cool to downvote somebody for asking you to clarify what you mean with “scaling”. If you want to know what you can do to prevent your projects from sinking into chaos: 1) Use a framework, even if it isn’t “Perfect” it is at least documented which is something you seldom have time for when you are working on your own. (I’ve never worked on an in house framework that was documented, I’ve worked on a lot of of in house frameworks) Edit: Angular, Ember.js and maybe even Next.js are frameworks. Vue and React are not. You need more than presentation. 2) Settle on something for forms authentication eminently and make sore to keep to it. Doesn’t mater if it is frontend only, backend only or a mix. If you use a lib or if you do your own. This is one of the places where things can quickly become a mess so knock it out from the beginning. 3) Put as much of your logic into utility functions, service objects and so on as possible. Make sure you don’t pass huge “magic” objects into any of these functions and look into making them small, self explanatory and testable. You will need to reuse functionality a hell of a lot more than you think and having it mixed in with your presentation layer, or data layer will make it less testable and less reusable. Edit: Also utility functions and service objects are easier to test than testing the same functionality in the UI. 4) Your presentation layer will turn into something ugly quickly especially if all you do is your work so: a) Try do do small refactoring along the way and if things still get bad fight for the time for a larger refactoring so you spare yourself the rewrite. b) Your first draft of the code will do the job but to get to a simple and clear version takes work, even if it doesn’t look like it so try to check the “simple” version in to git and not the “working” version.
jcun4128 5y ago
Not sure if you mean maintainability/ability to add future stuff. With that in mind for me it's to do some form of breaking things up so the side effects/remembering is low. Sucks to make a change and have to remember how everything works. In this case tests are nice for regression.
- 2bor-2n 5y ago
  Yes that's exactly what i meant by scaling the frontend (maintainability and ability to add new features easily). What's the tech stack you use on frontend? And for testing which library do you prefer? Do you rely on unit and integration testing only to avoid any regression?
  - jcun4128 5y ago
    Just FYI I'm a mid-level SWE at this time. Not an expert. This is just what I've encountered (corp day job) and personal pains of my own code. I primarily use ReactJS. We used a domain-driven pattern. Although there is still that component parent hierarchy thing going on. TDD (tech design doc), write the code, linter, unit tests (Jest/Enzyme eg. render part of component take code snapshot, assert stuff) and then WDIO for visual regression testing (image diffs). It is a time consuming thing to setup but when you have like 600tests it's nice/assuring. Then it runs on a pipeline (Jenkins) for about an hour before it gets released to some domain. Personally I am still in the get it done/MVP stage. The above is ideal case when you're established/dealing with many other people changing code. I am going with a Selenium/functional test though personally for the thing I'm working on now (2-way real time interactive app). There's different ways to test stuff depends what your thing is. The TAs I worked with use Eggplant. The main thing though about separation of concerns is important when possible just to reduce cognitive load for the next stuff you add.
    - 2bor-2n 5y ago
      Thanks for the insight. BTW how many years of experience do you have?

2 points by 2bor-2n 5y ago

What are your strategies to scale up frontend? What process and coding style do you follow so that the project could scale up easily in the future?

johntdaly 5y ago

What is your definition of front end that it needs scaling? What is your setup that a proxy and CDNs aren’t enough scalability for a front end? I haven’t encountered a case where the front end is ever the scaling bottleneck so I have to assume that if it is in your case you either are doing something novel or you are defining something that is usually back end as front end.

johntdaly 5y ago
Dude, it is not cool to downvote somebody for asking you to clarify what you mean with “scaling”. If you want to know what you can do to prevent your projects from sinking into chaos: 1) Use a framework, even if it isn’t “Perfect” it is at least documented which is something you seldom have time for when you are working on your own. (I’ve never worked on an in house framework that was documented, I’ve worked on a lot of of in house frameworks) Edit: Angular, Ember.js and maybe even Next.js are frameworks. Vue and React are not. You need more than presentation. 2) Settle on something for forms authentication eminently and make sore to keep to it. Doesn’t mater if it is frontend only, backend only or a mix. If you use a lib or if you do your own. This is one of the places where things can quickly become a mess so knock it out from the beginning. 3) Put as much of your logic into utility functions, service objects and so on as possible. Make sure you don’t pass huge “magic” objects into any of these functions and look into making them small, self explanatory and testable. You will need to reuse functionality a hell of a lot more than you think and having it mixed in with your presentation layer, or data layer will make it less testable and less reusable. Edit: Also utility functions and service objects are easier to test than testing the same functionality in the UI. 4) Your presentation layer will turn into something ugly quickly especially if all you do is your work so: a) Try do do small refactoring along the way and if things still get bad fight for the time for a larger refactoring so you spare yourself the rewrite. b) Your first draft of the code will do the job but to get to a simple and clear version takes work, even if it doesn’t look like it so try to check the “simple” version in to git and not the “working” version.

jcun4128 5y ago

Not sure if you mean maintainability/ability to add future stuff. With that in mind for me it's to do some form of breaking things up so the side effects/remembering is low. Sucks to make a change and have to remember how everything works. In this case tests are nice for regression.

2bor-2n 5y ago
Yes that's exactly what i meant by scaling the frontend (maintainability and ability to add new features easily). What's the tech stack you use on frontend? And for testing which library do you prefer? Do you rely on unit and integration testing only to avoid any regression?
- jcun4128 5y ago
  Just FYI I'm a mid-level SWE at this time. Not an expert. This is just what I've encountered (corp day job) and personal pains of my own code. I primarily use ReactJS. We used a domain-driven pattern. Although there is still that component parent hierarchy thing going on. TDD (tech design doc), write the code, linter, unit tests (Jest/Enzyme eg. render part of component take code snapshot, assert stuff) and then WDIO for visual regression testing (image diffs). It is a time consuming thing to setup but when you have like 600tests it's nice/assuring. Then it runs on a pipeline (Jenkins) for about an hour before it gets released to some domain. Personally I am still in the get it done/MVP stage. The above is ideal case when you're established/dealing with many other people changing code. I am going with a Selenium/functional test though personally for the thing I'm working on now (2-way real time interactive app). There's different ways to test stuff depends what your thing is. The TAs I worked with use Eggplant. The main thing though about separation of concerns is important when possible just to reduce cognitive load for the next stuff you add.
  - 2bor-2n 5y ago
    Thanks for the insight. BTW how many years of experience do you have?