Server vs Client Execution

Where Does Code Run — and Why Does That Distinction Matter?

Every web application is really two programs: one that runs on infrastructure you control (the server), and one that runs on a machine you don't control at all — a stranger's browser, on a stranger's operating system, with a stranger's browser extensions and developer tools attached. That second program ships as plain text. Anyone who receives it can read it, modify it, and re-run it however they like.

This is not a performance detail. It's a trust boundary. Anything you compute or validate only on the client is a suggestion, not a guarantee — the server is the only environment where you can actually enforce a rule, because it's the only environment an attacker cannot rewrite before it executes.

/*
 * BEFORE — the discount rule exists only in the browser.
 * It looks correct in the UI. It enforces nothing.
 */
// Client-side JavaScript — this is the ONLY place this check exists
function calculateTotal(price, quantity, couponCode) {
    let total = price * quantity;
    if (couponCode === 'SAVE20') {
        total = total * 0.8;   // 20% off — computed in the browser
    }
    return total;   // sent to the server as "the total to charge"
}

// Server — trusts whatever number the client sent
@PostMapping("/api/checkout")
public OrderResponse checkout(@RequestBody CheckoutRequest request) {
    return orderService.charge(request.total());   // 💀 charges whatever number arrived
}
// A user with DevTools open, or simply calling the endpoint with curl,
// sends { "total": 0.01 } directly. Nothing on the server disagrees.

/*
 * AFTER — the browser still computes a total for instant UI feedback,
 * but the server independently recomputes it from data IT trusts
 * (its own product catalog and coupon table) and ignores the client's number.
 */
@RestController
@RequestMapping("/api/checkout")
public class CheckoutController {

    private final PricingService pricingService;   // constructor injection

    public CheckoutController(PricingService pricingService) {
        this.pricingService = pricingService;
    }

    @PostMapping
    public OrderResponse checkout(@Valid @RequestBody CheckoutRequest request) {
        // The client's total is never read. The server derives the real one
        // from the product price and coupon validity stored in ITS database.
        BigDecimal realTotal = pricingService.computeTotal(request.productId(), request.quantity(), request.couponCode());
        return orderService.charge(realTotal);
    }
}

public record CheckoutRequest(Long productId, @Positive int quantity, String couponCode) {}

What Belongs on Each Side

Server-Side — Runs on Infrastructure You Control

// Every line here executes on YOUR machine. The client never sees this code,
// only the JSON it returns.
@RestController
@RequestMapping("/api/users")
public class RegistrationController {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    public RegistrationController(UserRepository userRepository, PasswordEncoder passwordEncoder) {
        this.userRepository = userRepository;
        this.passwordEncoder = passwordEncoder;
    }

    @PostMapping("/register")
    @ResponseStatus(HttpStatus.CREATED)
    public UserResponse register(@Valid @RequestBody RegisterRequest request) {
        if (userRepository.existsByEmail(request.email())) {
            throw new EmailAlreadyRegisteredException(request.email());
        }
        String hashed = passwordEncoder.encode(request.password());   // hashing NEVER happens client-side
        User saved = userRepository.save(new User(request.email(), hashed));
        return new UserResponse(saved.getId(), saved.getEmail());
    }
}

public record RegisterRequest(@Email String email, @Size(min = 10) String password) {}
public record UserResponse(Long id, String email) {}

Client-Side — Runs Inside the User's Browser

The example below is plain JavaScript on purpose — the split described in this topic exists independently of any frontend framework. React, Vue, and Angular formalize this pattern with components and reactive state, but the underlying rule (this code runs in the browser, and only the browser) is identical either way.

// This executes in the browser — the user's CPU, the user's memory.
const form = document.getElementById('registrationForm');

form.addEventListener('submit', async (event) => {
    event.preventDefault();

    const email = document.getElementById('email').value;
    const password = document.getElementById('password').value;

    // Client-side validation — purely for immediate feedback.
    // It improves UX; it enforces NOTHING. The server repeats every check.
    if (!email.includes('@')) {
        showFieldError('email', 'Enter a valid email address');
        return;
    }
    if (password.length < 10) {
        showFieldError('password', 'Password must be at least 10 characters');
        return;
    }

    const response = await fetch('/api/users/register', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ email, password })
    });

    if (!response.ok) {
        showFieldError('email', 'This email is already registered');
        return;
    }
    window.location.href = '/welcome';
});

The Complete Picture: A Login Request End to End

Following one request across the boundary makes the split concrete. Note where the authentication token ends up — this is the part most tutorials get wrong.

// ── STEP 1: CLIENT — user submits the form ──────────────────────────
const response = await fetch('/api/auth/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    credentials: 'include',   // tells the browser to store/send the cookie the server sets
    body: JSON.stringify({ email, password })
});

// ── STEP 2: SERVER — the only place identity is actually verified ───

@RestController
@RequestMapping("/api/auth")
public class AuthController {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;
    private final JwtService jwtService;

    public AuthController(UserRepository userRepository, PasswordEncoder passwordEncoder, JwtService jwtService) {
        this.userRepository = userRepository;
        this.passwordEncoder = passwordEncoder;
        this.jwtService = jwtService;
    }

    @PostMapping("/login")
    public ResponseEntity<Void> login(@Valid @RequestBody LoginRequest request) {
        User user = userRepository.findByEmail(request.email())
            .filter(u -> passwordEncoder.matches(request.password(), u.getPasswordHash()))
            .orElseThrow(InvalidCredentialsException::new);   // same error for "no such user" and "wrong password"

        String token = jwtService.generateToken(user);

        // The token is set as an httpOnly cookie. JavaScript in the browser
        // can never read this value — that's the point (see Section 3).
        ResponseCookie cookie = ResponseCookie.from("auth_token", token)
            .httpOnly(true)
            .secure(true)
            .sameSite("Strict")
            .path("/")
            .maxAge(Duration.ofHours(1))
            .build();

        return ResponseEntity.ok()
            .header(HttpHeaders.SET_COOKIE, cookie.toString())
            .build();
    }
}

public record LoginRequest(@Email String email, @NotBlank String password) {}

// ── STEP 3: CLIENT — the browser already stored the cookie automatically ─
if (response.ok) {
    window.location.href = '/dashboard';
    // No token to read, no token to store manually. Every subsequent
    // fetch() with credentials: 'include' sends the cookie automatically.
} else {
    showError('Invalid email or password');
}

Security: Never Trust the Client — Including Where You Store Its Secrets

// The attack requires no special tooling — just curl.
curl -X POST https://shop.example.com/api/checkout \
     -H "Content-Type: application/json" \
     -d '{"productId": 1, "quantity": 1, "total": 0.01}'

// If the server in Section 0's "BEFORE" example is still live,
// this charges one cent for any product. The fix is not "add more
// JavaScript validation" — it's "never read request.total() at all."

Where the HTML Gets Built: SSR, CSR, and Hybrid Approaches

Server vs client execution isn't only about business logic and security — it also determines where the HTML itself is assembled. This is a separate axis from everything above, and it's usually decided per-application, not per-request.

Server-Side Rendering (SSR)

// Thymeleaf — the server sends complete, ready-to-paint HTML
@GetMapping("/products")
public String productList(Model model) {
    model.addAttribute("products", productService.findAll());
    return "products";   // resolves to products.html, rendered server-side
}

<!-- products.html — filled in BEFORE the browser ever sees it -->
<ul>
    <li th:each="product : ${products}">
        <span th:text="${product.name}"></span>
    </li>
</ul>
// The browser receives finished HTML — no JavaScript required to see content.

Client-Side Rendering (CSR)

// Server — a pure JSON API, no HTML at all
@GetMapping("/api/products")
public List<ProductResponse> getProducts() {
    return productService.findAll();
}

// Client — plain JavaScript builds the DOM after fetching JSON
async function renderProductList() {
    const response = await fetch('/api/products');
    const products = await response.json();

    const list = document.getElementById('product-list');
    list.innerHTML = products
        .map(p => `<li>${p.name}</li>`)
        .join('');
}
// React, Vue, and Angular automate exactly this fetch-then-render cycle
// with reactive state instead of manual innerHTML rewrites.

Hybrid: Server HTML Fragments Without Full Reload

The dominant pattern in 2026 is not "pick SSR or CSR" but combine them: render the initial page on the server for speed and SEO, then swap only the fragments that change. HTMX is the clearest example of this in a Java/Spring stack — no JavaScript framework required.

@GetMapping("/products/search")
public String searchProducts(@RequestParam String query, Model model) {
    model.addAttribute("products", productService.search(query));
    return "fragments/product-list";   // only the fragment, not the full page
}

<!-- The server renders HTML; HTMX swaps it in without a page reload -->
<input type="search"
       hx-get="/products/search"
       hx-trigger="keyup changed delay:300ms"
       hx-target="#results">
<div id="results"></div>

Best Practices and Common Pitfalls

Interview Questions