Evolution of web development and modern architecture

For example, a company profile page in the 1990s could send the same file to every visitor. But when shopping carts, message boards, and online banking required different state for each user, servers had to read cookies and sessions from requests and insert database results into HTML. The screen was still a complete document, but producing it changed from copying a file to executing a program.

Knowing this history helps avoid labeling static pages as old and dynamic applications as new. Help content that changes rarely can use prebuilt HTML for faster delivery and fewer failure points. In contrast, live inventory and personal permissions require request-time computation. For each page, first decide who produces the content, when it is regenerated, and how stale a result is acceptable on failure.

In early server applications, URL handling, SQL, business rules, and HTML assembly tended to collect in a single request function. A small screen change could end up touching database queries, and adding a mobile app meant reimplementing the same rules. Separating frontend and backend was an attempt to divide code that changes for different reasons along a reviewable boundary called an API.

In an online order, the frontend can display amounts clearly and flag input errors quickly, but the backend must independently determine the final discount and inventory deduction because users can modify browser values. The key boundary is therefore where untrusted input is validated and which state changes are allowed only once, not which team uses which language.

If a product-card component requires `price: number` but the API adapter passes a string, TypeScript can reveal the contract mismatch before the build. However, if the server actually returns a string meaning free and the developer forces a type assertion on the response, the check passes. Static types only check connections between already-known contracts; they do not observe facts outside the network boundary.

In practice, validate external input against a runtime schema, convert values that pass into domain types, and then pass them to components. Component tests check how the loading, empty, error, and normal states appear. Separating these three layers finds type errors, bad external data, and UI behavior errors in different places with shorter feedback loops.

A rendering strategy determines when and which bytes to send to the user, not merely a page's name. Public documents can be rendered into HTML at build time and cached on a CDN for a long period. Order history after login requires authorization on each request. For tables with frequently changed filters, it may make sense to fetch some data in the browser after loading the initial structure.

In a hybrid strategy, cache keys and invalidation become the most important operational contract. If user A's response lands in a shared cache, that is a security incident; if a product price is updated but a static page remains, that is a business error. Recording for each route whether it is personalized, how long updates may lag, which functions must work without JavaScript, and what fallback to show on error lets you choose the right boundaries before reaching for framework terminology.

When a user clicks the payment button, success of the browser event alone is insufficient. The request must pass through DNS and TLS and be authenticated at the gateway; the API must check the idempotency key; the database transaction must update orders and inventory together; and the same order status must remain queryable even if the response is lost. This is why a 200 response from any one layer cannot establish end-to-end success.

When drawing a request map, record the evidence left at each boundary rather than component names. The browser should retain the result shown to the user, the gateway the request ID and authenticated subject, the API the revision and business errors, the database the transaction result, and the deployment layer the image digest. Only when these identifiers are linked can you narrow an incident to the frontend, cache, or query through evidence rather than guesswork.

In a teaching fixture, delay A by 800 ms and B by 100 ms to reverse response order. These values are test conditions for reproducing ordering errors, not measured service performance. Use a mock that independently releases each response instead of relying on timer luck. This reproduces the same causal ordering even on slow test machines.

After B appears, release A and verify that both the visible query and result identifiers remain associated with B. A test checking only request counts can miss a stale result overwriting the screen. Check both the first visible item and its link target ID. A B title with an A link is a mismatch between appearance and actual user action.

Add failures to the same fixture and check that error messages also belong to the current request. If A’s late failure replaces B’s successful screen, only the success path has been fixed. Check whether error state carries its request ID. One shared error boolean cannot distinguish a past request’s failure from the current request’s failure.

Record query conditions, applied and discarded response IDs, and visible results. The next reviewer should reproduce the same sequence and confirm failure before the fix and success afterward. Also check that discarded responses are not double-counted as successful visible results. Network responses and results actually viewed are different metrics; combining them changes the interpretation.

Test a teaching completion button by seeding saved completion before opening the page. Wait within a bounded interval for the button to restore while the article DOM remains intact, rather than assuming one short fixed delay is sufficient. If the deadline expires, retain initial storage and final button state as failure evidence rather than passing. This distinguishes delay from missing restoration behavior.

After restoration, click to clear completion and then complete it again. Both the accessible button state and stored value must change each time to establish that events and persistence work. If the UI changes without persistence, reload brings the old state back. Verify that the final click actually records the value needed when reopening the page.

A native details disclosure can work without JavaScript, so testing only that may pass even when client code never runs. Keep an actual React-state interaction and readable no-JavaScript content as separate evidence. A fixture blocking JavaScript does not demand a working completion button. It checks readable headings and content links, keeping the two tests’ responsibilities separate.

Separate missing initial HTML, invalid asset paths, failed state restoration and failed persistence after clicking. Distinct reports identify whether SSR generation or a client effect needs repair. After repair, test both first and returning visits. Testing only empty storage can keep mismatches in personal-state restoration hidden.

Open a fictional product list with category=books and page=3, then select an item. Compare whether a copied URL in a new tab and back navigation restore the same filters. The detail link must preserve conditions for returning to the list. Check browser-history navigation as well as any custom back button.

Create fixtures with page=-1 and an unsupported sort value. Decide in advance whether to show an error or fall back to defaults, then check the resulting URL, request conditions, and on-screen display against the agreed rule. Supply the same invalid value through both server entry and client-side filter changes. An error in one path and a silent default in the other can make a shared URL behave differently for different users.

If old results remain visible on a slow connection, indicate which conditions they represent. Showing a new URL alongside old results labeled current can cause users to select the wrong item. Tie loading completion to success for the requested conditions. An unrelated early response must not clear loading and imply that new results are ready.

Completion evidence includes direct entry, reload, back navigation and invalid URL input, not one link click. Consistent interpretation across these paths makes state shareable rather than dependent on temporary memory. Preserve previously shared-link fixtures when changing the URL contract. State design that works only on the new screen can strand bookmark and external-link users.