Like many Javascript-based rich web apps these days, I have some complicated validation rules implemented on the front-end. The same rules are supposedly repeated exactly on the Java backend but I always find small deviations.

As a believer of the DRY principle, I think something should be done to systematically fix this. Ideally both sides should run the same code and use the same rules, but since running JavaScript on the backend is not allowed, I can only hope to reuse some meta-fied validation rules. Fortunately, I found some library on GitHub that can do this for JSR-303 annotation-based validation. However, a lot of rewriting and refactoring is still required.

On the other hand, the number of rules is limited (< 80 in total) and the current code is clear and simple to understand (just a bunch of if statements). Using a validation framework would require all custom validators to be wrapped and hidden behind generated meta-data not immediately visible during development, so loads of additional learning curve.

It seems my goal to improve the code will really just harms maintainability. What's people's experience on this?

2 Answers 2


You could use some rule-based DSL to specify the validation rules used by both the front and back ends. This though then requires code on both the front and back ends to read and implement those validation rules. This leads to the problems that the validation rule reading and implementing code has to be written twice. This can still lead to inconsistencies, and it adds to the size of your code base, increasing its complexity.

The way to reduce code complexity and the risks of inconsistent rule checking is to offload all validation to the server side. The JavaScript code then uses AJAX calls to request the back end validate the input. The front end knows nothing about the validation rules, it simply gets told whether the input is valid or not.

  • I do agree that this is the best solution to the asker's problem, it will however, come at the cost of performance
    – CurlyPaul
    Sep 29, 2015 at 15:00
  • @CurlyPaul, that is indeed the trade off. I'd always advise addressing performance only if it's an issue. If the speed of having the client use the server for validation is fast enough, then all well and good. Otherwise, a more complex, more performant solution should be adopted.
    – David Arno
    Sep 29, 2015 at 15:06

In my experience the validations on client and server often differ for good reason.

Generally a server side, low level process will throw an exception, with perhaps a short description, maybe an error number. This is meant for logging to an error log rather than showing to an end user.

While a client side error is processed prior to making a call and will present the user with a descriptive error message, in their own language, perhaps with UI elements highlighting the problem.

this leads to a difference in both the way the validation is done, the error message returned and otfen the actual logic of the validation.

for example take my favorite example, the long form presented as a 'wizard' set of short forms with validation at each step. The Validation of the user input is going to be split up and done at each stage. Where as the server side logic will be expecting all the data at once.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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