Form validation code shared in the frontend and backend API?

Question

I have a legacy Java monolithic web application. My goal is to use React on the frontend, keep Java on the backend and add an API for the frontend to use.

My question is how can I write the data validation just once, using it on both the frontend for form validation and on the backend for data validation?

With the API written in java and the data validation written in javascript, is a workable solution to have an intermediate validation proxy API written in javascript+nodejs which then passes validated requests to the java API?

React(js validation) -> nodejs-API(js validation) -> Java-API(no data validation)

• Laiv: Java-API(no validation) you are assuming there would be always "something" in front of the JAVA API doing validations. You are also assuming that whatever lays in front of Java API has no bugs. Too many assumptions. On the other hand, validations are part of the business. Why decouple them? Why make things so complicated just to reuse a bunch of "if null, if empty, ....". What's the goal? What's the problem to solve?
• Dan: Thank you for the reply. The Java-API(no validation) would ony be accessible by the nodejs-API. It's a complex business web app with a ton of validation currently written in Java. The goal would be to rewrite the validation logic to JS and not maintain the same validation in both JS and Java. I'm not sure what you mean about bugs.. that risk exists even with just the single Java API.
• Laiv: The goal is still unclear. You are not migrating the API from Java to Js, just splitting logic into 2 different components. All these validations are part of the business so they should remain close to the business. If a gateway starts gathering business rules, then it's no longer a gateway. It's something else. that risk exists even with just the single Java API yes, but with your design, you have 2 components to test and debug to find where the bug is at.
• Laiv: On the other hand, what if the gateway needs something from the Java API to perform the validations? The gateway will start then a dance of request to the API, complicating the sequence of actions. It's likely some more logic will be moved to the gateway (even DB connections) to prevent this. Then what? IMO you have to find a better reason to take forward this design than a mere "code reuse". Such code reuse doesn't offset the cons (complexity) because usually, business and validations are tightly related to each other. But I could be wrong, I don't know all the details.

Answer 1

Two points:

1. Validation in the UI is designed to illicit corrections from the user.
   • Human readable explanations
   • UI alert indicators
   • dynamic checking
2. Validation in the backend is designed to prevent nasty security issues.
   • pass/fail
   • fail fast
   • single pass

While they both do "validate" the document:

• their intentions are quite different: online vs. offline, full vs. fail fast, verbose vs pass/fail.
• the resources available are different: Gigabytes vs. MegaBytes, Multiple threads vs. One thread
• and the sheering forces acting on the code is different: Browser Architectures vs. Server Architectures, the frameworks, and languages, etc...

Just to get this to work, as you've just pointed out, you would need to:

• reorganise your network architecture,
• adopt a new platform,
• ensure you validation library is poly-fillable for both browser and server usage.

That is a high price to pay for de-duplicating just 2000 lines of code.

• Dan: Thanks. Good points. Duplicating the validation code might not be worthwhile once we begin using automated testing, where we currently have testers doing everything manually. I would think just about all our frontend validation logic would also need to be on the backend so we have data integrity. If something isn't allowed on the frontend then we shouldn't allow the backend API accept data which doesn't conform to the validation logic of the frontend.
• Dan: I'm thinking we'll still have an api gateway in front of the new API added to the legacy Java app so we can migrate functionality out of the legacy app and into services.
• Andremoniy: Code duplication is always an evil and must be avoided by any cost.
• Kain0_0: @Andremoniy Duplication isn't evil. There are many useful forms of it, such as when we instantiate an object, for the second time; when we write a test that describes our system, as after-all the system is code, and code is a description; and as above the same business requirement such as a field being an email address should be validated in UI, but also must be validated in the API possibly using different languages/ways of expressing validation failure. I do agree that so much duplication actually represents incidental complexity, and that should always be reduced as technically possible.