Business logic and input validation

In Module 1, you learned that business logicConcept · lights on your mapbusiness logicRe-encounter from Modules 1 and 3: the collection of rules that determines how a product behaves. It can run on both sides of an application, but rules involving money, permissions, security, or authoritative data must be enforced by the backend. is the collection of rules that determines how a product behaves.

In Module 3, you saw those rules expressed as code, when a delivery-fee function decided whether a customer qualified for free delivery based on membership status and order total.

Now we can place those rules within the frontend–backend model. Business logic can exist on both sides of an application, but rules involving money, permissions, security, or authoritative data must be enforced by the backend because the company controls the server-side environment.

A useful principle is: the frontend can suggest and preview the rules. The backend makes the authoritative decision.

Business logic on both sides

Some business logic runs on the frontend to make the product feel immediate. When someone enters a discount code, the frontend can notice an empty field or invalid characters and answer at once, with no server trip: “Please enter a valid coupon code.” But the frontend runs on machines users control, so Lesson 1 already established that these quick checks should not be the final authority for important rules.

So the backend independently enforces the rules that affect the product’s official state. When the frontend says a coupon provides a 20% discount, the backend should still verify:

• Whether the coupon exists
• Whether it has expired
• Whether the user is eligible
• Whether the order meets the minimum amount
• Whether the coupon has already been used
• Whether it can be combined with another promotion

The frontend can display an estimated discount, but the backend calculates the official total before the customer is charged. This protects the product from mistakes and manipulation.

What is input validation?

Input validationConcept · lights on your mapinput validationChecking information before a system accepts or uses it: is it present, the expected type, within range, in the required format, actually supported? Done client-side for fast feedback and again server-side before trusting it, with the database adding another layer later. is the process of checking information before a system accepts or uses it.

Applications receive input from many places:

• Forms
• Buttons
• Uploaded files
• Mobile applications
• APIs
• Other internal systems
• Automated scripts

The receiving system must check whether that input meets its expectations.

For example, an order request may need to contain:

• A recognized drink
• An allowed size
• A positive quantity
• A valid store location
• All required fields

Validation asks questions such as:

• Is the required information present?
• Is each value the expected data type?
• Is the value within an allowed range?
• Does it follow the required format?
• Is the requested option actually supported?

Validation prevents the rest of the system from blindly using malformed or unacceptable information.

Client-side validation

Client-side validation happens on the user’s device, usually in the frontend.

Consider a simplified order form. The frontend might check whether the quantity is below one:

This gives the user immediate feedback and may prevent an unnecessary server request.

Other client-side checks might confirm that:

• An email address has a recognizable format
• A required field is not empty
• A password meets the visible requirements
• A date is within the allowed range
• A file is not obviously too large

These checks are useful, but they are not sufficient by themselves.

Why the backend must validate again

A server cannot assume that every request came through the official frontend. This is Lesson 1’s warning made concrete.

A person can use browser developer tools to modify the page, a script can send a request directly, and an outdated version of the mobile app may submit information the current frontend would reject.

For example, someone could send this request without using the application’s interface:

The backend should not assume that the quantity and price are valid merely because they appeared in a request. It must perform its own checks:

The backend rejects the invalid quantity and retrieves the official price instead of trusting the price supplied by the client, which is the meaning behind a common engineering principle: never trust client input.

It does not mean that every user is malicious. It means the server should treat incoming information as unverified until it has been checked.

Why validate on both sides?

Client-side and server-side validation serve different purposes.

Client-side validation improves the user experience. It is fast and can explain simple problems before the request is sent.

Server-side validation protects the system’s correctness and security. It runs in an environment the company controls and cannot be bypassed merely by changing the frontend.

The same information may therefore be checked twice:

1. The frontend checks it to help the user.
2. The backend checks it before trusting or acting on it.

This is intentional duplication, not wasted work.

When the data eventually reaches a database, the database may enforce additional rules as another layer of protection, and you will explore those constraints in the data module.

Validation has limits

Validation confirms that input follows the rules the system knows how to check.

For example, it can confirm that an email address has the expected shape: name@example.com

That does not prove that the address belongs to the user or that someone actively reads it. A separate verification process may be required.

Similarly, validation can confirm that a price is a positive number, but the system still needs an authoritative source to determine whether it is the correct price.

Validation therefore asks: is this input acceptable for the system to process?

Other checks may still be needed to determine whether the information is accurate, authorized, or trustworthy.

Static and dynamic behavior

This frontend–backend split also connects to the distinction between static and dynamic content, which you met in Module 4.

Static contentConcept · lights on your mapstatic contentContent prepared in advance and reusable across users: a logo, an article, a stylesheet. Unlike dynamic content, it needs no backend work per request, which is why it is cheap and fast. is prepared in advance and can often be served in the same form to many users. So a logo, a stylesheet, or an informational article may require relatively little backend processing after the files exist.

Dynamic contentConcept · lights on your mapdynamic contentContent generated, selected, or updated for the current user, request, or system state: your balance, your feed. Unlike static content, every view of it costs backend work. is generated, selected, or updated according to the current user, request, or system state. So your shopping cart, your unread messages, or an order’s live status usually depends on backend logic, stored data, authentication, and requests between systems.

Most products contain both

Static and dynamic are not absolute categories for entire products.

A restaurant website may have mostly static information, but its reservation form could be dynamic. A banking application contains highly dynamic account information, but its help pages and icons may be static.

A team designing a feature may ask:

• Can this information be prepared in advance?
• Must it be calculated for each request?
• Is it different for each user?
• How current must it be?
• Does it depend on stored state?
• Does it require a backend at all?

The more a feature depends on current data, personalized rules, permissions, and stored state, the more backend work it is likely to require.

But frontend complexity can also be substantial. A highly interactive design, real-time collaboration tool, or advanced visual editor may require significant client-side engineering.

The amount of work depends on the complete experience, not merely which side of the application it belongs to.

Seeing the complete order flow

This is Lesson 1’s complete flow, now with the rules filled in. A customer places an order using a coffee app, and the frontend first checks whether the required fields are present; if the quantity is missing, it immediately asks the customer to correct it.

Once the basic client-side checks pass, the frontend sends the order to the backend.

The backend then:

1. Validates the request again.
2. Confirms the customer is allowed to order.
3. Retrieves the official product price.
4. Checks whether the store and item are available.
5. Applies discounts and other business rules.
6. Saves the accepted order.
7. Returns a response to the frontend.

The frontend then displays either a confirmation or an explanation of why the order could not be completed.

The frontend helps the user complete the journey. The backend protects the official rules and state.

The mental model to remember

Business logic is the collection of rules that determines how a product behaves.

Some business logic can run client-side to make the experience feel immediate.

Important rules must also be enforced server-side because the client can be inspected, modified, or bypassed.

Input validation checks whether submitted information meets the system’s expectations.

Client-side validation helps the user. Server-side validation protects the system.

Static content can often be prepared and reused, while dynamic content depends on the current user, request, data, or system state.

You should now understand why the frontend can preview a result while the backend independently validates the request and determines the authoritative outcome.