Few month ago, we created a logic to calculate customer progress in JavaScript. We didn't thought that it will be useful if we store them in our database.

Now, i'm facing 2 options,

  1. Rewrite calculation_pogress in ruby (our server side programming language).
  2. Create an API endpoint that catch the value from clients.

Is it worth for me to rewrite it in ruby ? Are there any other options ?

  • recommended reading: What is the problem with “Pros and Cons”?
    – gnat
    May 21, 2015 at 4:46
  • Thanks. I've updated the questions and remove the pro and con . do you mind to review it and give some feedback ? @gnat May 21, 2015 at 4:55
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    May 21, 2015 at 4:57
  • 1
    i'll revisit this question as i found out that my question should be updated to meet community guidelines. Thanks for all of your recommendation. May 21, 2015 at 5:13

2 Answers 2


Remember that anything coming from the client side has to be treated as untrusted. If you actually make some decisions based on "progress" it would be better to calculate it on the server side.


The main purpose of best practices like DRY is not to make things easier for you, but to make things easier for future you(and for other people who'll work on the project). They care less about the process of coding and more about the final result. Of course, that doesn't mean the process is not important - but that's a concern for development methodologies and business planning(which you also need to balance)

In that regard, rewriting the logic for the server doesn't violate DRY - what could violate DRY is keeping both client and server side implementations and using them both. The rewriting itself creates work for you, but if once it's done you end up with a better application it can be worthwhile. Keeping both versions means you have to keep them in sync(changes to one must be replicated in the other), which makes the project harder to maintain. It's a problem for future you.

Now, like ddyer said in the other answer - if you send that data from the client to the server the server needs to validate it. So the main question is:

How complex is the to validate the progress compared to the calculating the progress?

If validating the progress is as complex as calculating it, you'll have to keep them in sync, which makes the project harder to maintain. It's different than having to syncing the two calculation implementations(Easier because bugs will pop earlier when validation code rejects progress that should be OK. Harder because there is no longer almost-one-to-one mapping between the logics), but it's still a problem for future you.

On the other hand, if validating the progress is much simpler than calculating it, you might consider calculating in the client side and sending to the server side. You should, of course, take into account things like:

  • Is the progress calculation requires lots of client/user interaction? If the server for example, will have to contact the client to ask the users questions, and needs these answers before the user can proceed, all this ping-pong can be prevented if the calculations are done client-side.
  • If the progress calculation is mainly for displaying it to the user, and you only need it at server side for logging purposes, it can be easier and produce better results for the client to do the calculation itself instead of having the query the server each time it wants to update the progress display.
  • How much work is it to reimplement the logic compared to implementing the API for transferring it between client and server?
  • Do you want to allow third party clients? If so, if the logic is at client-side they'll need to reimplement it...

And so on - the point is these should be considered only if the validation logic is simple(which means you can probably do many changes to the calculation logic without having to change the validation logic), since having to sync complex validation logic with complex calculation logic will make the project harder to maintain.

Not the answer you're looking for? Browse other questions tagged or ask your own question.