0

Which application layer(s) should be responsible for user input validation? I think there are two schools of thought:

  1. The frontend should make no assumptions as to what constitutes valid data, the backend knows better. Unless your server is located on the Moon, there's no cost worth thinking of.

  2. There are things that don't take the backend to figure out. For example, the frontend can check required fields for blankness, or check if a "from" date is earlier than a "to" date. Performing such checks on the frontend is cheaper and makes for a more efficient application.

What's your take?

Improve this question
9
  • 4
    Backend has to validate data. Period. Adding additional validation on the frontend side can be seen as an optimization (reduces client-server communication). At the cost of higher complexity and consistency issues. So mixing both is a valid approach. But backend is a must have. Commented Feb 9 at 8:09
  • 1
    The answer is completely different from the perspectives of UX design, security and software engineering, so you'll hav to tell us what your primary design criterion is. Commented Feb 9 at 13:33
  • @KilianFoth it's a software engineering question Commented Feb 9 at 14:11
  • 2
    @KilianFoth: software engineering contains the capability to reconcile different aspects like UX design, security and evolvable software architecture, and to make the suitable trade-offs. So I would not expect a primary design criterion to be necessary for this question. Commented Feb 9 at 14:55
  • Each layer of an application (however you wish to define layer) needs to test, and validate its input to the level that it needs. This is why strongly typed objects are so handy, because to have an instance of one indicates a certain level of validation, and can hence absolve that layer of further validation, as the type is already valid enough. Commented Feb 10 at 4:08

3 Answers 3

Reset to default
6

The backend cannot make any assumptions about the data it receives, because there is no guarantee that the data originated from your frontend. For this reason, the backend must perform a full validation of the data.

On the other hand, doing validations also on the frontend can give a better user experience, especially if the backend is designed to receive a complete form worth of data.
It just gives a better experience if you can give feedback as soon as the user removes focus from an input, rather than waiting till the entire form was submitted.

Improve this answer
3
  • OP suggests to send input to backend and display response interactively, there is never a need to submit. Commented Feb 9 at 9:59
  • 1
    @Basilevs, that depends on the design of the interaction between the front and backend. If I can write my answer in a way that is applicable to multiple designs, I try to do so to help more people than just the OP. Commented Feb 9 at 15:09
  • Yes, "when" is not part of the question. You can adopt the first approach and still validate on focus loss. The question is whether the frontend can make assumptions as to data validity or not Commented Feb 12 at 9:56
2

There is a subtle point here in that the backend doesn't have to do what i would call "Full validation"

ie return nicely formatted error messages in the language of your choice telling you exactly what's wrong with the input.

Where the front end might want to say "spaces are not allowed in phone numbers and you have one at character 4, plus your email isn't filled in" the backend can just go "Error bad request", assuming that the "Full Validation" is done on the FE

This pattern helps you avoid duplicating the full logic on both front and backend and forcing all your endpoints and models to handle sets of validation messages.

Improve this answer
4
  • 1
    But then the the logic is duplicated. And discrepancies in validation procedures might be very confusing. Commented Feb 9 at 9:58
  • 1
    its not duplicated becuase the FE one has more detail Commented Feb 9 at 9:59
  • 2
    They are in a sense, that most of the time they are modified together. Commented Feb 9 at 10:01
  • 1
    Many frontend frameworks, and even backend frameworks that offer form validation, are purposefully decoupled from anything business logic related. It is, unfortunately, very typical for "validations" to be duplicated business logic and frontend. I don't think of it as duplication. Validation is a form of pre-check done so the business logic layer doesn't throw exceptions. Commented Feb 9 at 14:48
0

For 3-tier applications...

|    Frontend     |                 Backend                |
|--------|--------|--------------------|-------------------|
| Client | Server | Business (Service) | Data Access (DAO) |
|--------|--------|--------------------|-------------------|

...there are specific concerns to validate for each layer/tier. Front-end should have knowledge about data the back-end needs to do its business. Business shouldn't have knowledge of data access environment particularities.

Examples/samples:
    Front-end: data format (string are strings, dates are dates), compulsory values are included.

    Back-end (business): data integrity (starting or ending date is in the future. If the start and end of an interval exist the type of business concept it is bounded type, conversely unbounded type with bounded interval cannot exist. For business concepts supporting just known values the value it is among the known ones).

    Back-end (data access): The special characters for persistent environment are encoded/escaped.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.