Wow..so i can’t believe this but i just got told by my “senior” in company that he “knows his shit” when i tried to give him constructive feedback on why doing calculations for users on backend is a bad idea and is not going to scale very well.
I mean we could do those calculations on frontend using web workers ( if they are so complex ) and that would have been clearly a better idea.

I also tried to give him feedback on why its a bad idea to couple backend apis with frontend. Honestly, i don’t feel like giving any sort of feedback anymore. I don’t even feel like trying my best to “improve” the codebase because if its going to be maintained by shitheads like him that get their pride easily hurt, then no matter how hard i try to improve it, its going to end up shit either way.

  • 4
    Can't form an opinion, need more info. What were the calculations?
  • 0
    @SortOfTested We are building a dashboard for our users that shows the performance of their employees. So the input is the data about the regular activities of the employees on our platform like how many deals they closed this week, how many new customers the employees got in contact with, etc. So the calculation is mostly the sum or some other operation on columns and rows of such data.
  • 9
    Doesn't business logic belong in back end?
  • 0
    And if you are wondering if there is any pagination involved, then no, there is no pagination
  • 0
    I will take an example for what i mean by coupling, so there is a x value and a y value and our FE requires to show x-y value. What BE is doing right now is that its sending x, y and also x-y just so that our ui doesnt have to do x-y calculation
  • 3
    Outside of say rando 'basic' (that's vague I know) calculations ... yeah I'd very generally lean towards doing that on the back end.

    Granted I don't know details but not wanting to do it on the back end would raise an eyebrow from me generally and I'd want to know more about what is up.
  • 7
    Hard to say. His reaction was definitely dismissive, and could be worded better.

    I am also wary of sending anything other than finalized payloads to the front end, because (as @Demolishun mentioned), business logic should be internalized on the server, for reasons both IP and user responsiveness related. It's a question a concerns.

    Without seeing the code I can't really make a call. Don't let his bullshit get to you. ✌️
  • 2
    Many many many unknoen variables here.

    If it's a static site that displays information only, it makes sense to put it into backend.

    If there is a lot of intertwined information, backend (conversation rates, different taxes / factors / ... )

    If it's a largely dynamic site - REST and query penetration imho.... Asking the backend for information and doing _small_ tasks.

    Juggling with tons of information in frontend usually ends bad TM. Especially involving intertwined information.
  • 2
    I understand the "can't take constructive feedback" part, but I wonder if the other part is "does not handle rejection well" may be playing a factor.
  • 0
    Another problem could be that the meaning and values of x and y change. So that doing x-y no longer makes sense. If its all back end you don't have to change the front end.
  • 1
    Think what you want bro. We are building a SPA using React and all the data thats needed for calculations should already be there on FE, because we need to show it to the user.
    The reason that i was told that they are doing the calculations of data on BE (there is no magic number involved in these calculations) was because they wanted to render the ui as fast as possible because doing those calculations on FE apparently caused the ui to load slow
  • 2
    Good, now you see it's a coin about two sides. If you calculate on frontend, you've got to wait for whole payload, latency of which is proportional to entries count. Having simple API on place seems like more scalable solution to me.
  • 0
    We always hear the ranter’s side in the stories.
  • 0
    From what I've seen in this thread, I don't see a reason why you shouldn't do the calcs in the BE - and generally speaking business logic belongs to the BE, and in my opinion all heavier calcs that could otherwise slow the UI rendering payload, unless the calcs relied on data changing via user input and the results were to be used reactively. It sounds like in this case your senior does know his shit - however, he really should've expressed himself better and maybe talk you through it why he thinks the calcs should stay in the BE.

    Now, a little addition based on a hunch and a real story: I don't know the dynamics between you, OP, and your senior, but is there a possibility he's just getting annoyed at you and hence the attitude? I observed a dynamic between a senior and a junior at our office not long ago, where the junior had this besserwisser attitude to things, and kept on arguing even when the senior (and everyone else present) clearly explained to them why whatever they were suggesting was a really bad idea. That just went on so long the senior just started replying with clearly annoyed snarky comments and this "are you fucking kidding me?" look at their face.
Add Comment