Where are the boundaries of Web Server, WAS, and Frontend?

May 1, 2026

—

cslab

in IT Security

“Web is static, WAS is dynamic” – is that formula we memorized still valid today?

What this article covers

Traditional division of roles between Web Server and WAS
Are Frontend/Backend subcategories of WAS?
Why Frontend also has a WAS in modern architecture
A framework for thinking to reduce terminology confusion

Why is this topic confusing?

There are questions that even junior developers, and sometimes experienced ones, hesitate to answer.

Is a Next.js server a Web Server or a WAS?

A React app is frontend, so it’s not a WAS, right?

What’s the difference between SSR and WAS?

The problem is that the textbooks we learned from were written based on Java web architecture in the early 2000s. At that time, Frontend and Backend ran almost within the same WAS. But now, it’s a completely different world.

Traditional Perspective — Web Server vs WAS

First, let’s clarify the original definitions.

Role of Web Server

A server that responds with static content. It delivers HTML, CSS, JavaScript files, images, fonts, etc., as they are, without changing their content upon request.

Representative products are Nginx, Apache HTTPD, and their characteristics are as follows:

Fast (reads files from disk and responds immediately)
Supports many concurrent connections
Does not execute business logic

Role of WAS

A server that generates dynamic content. It queries the DB, runs conditional statements, and combines results to create a response based on user requests.

Representative products are Tomcat, JBoss/WildFly, WebLogic, and their characteristics are as follows:

Executes business logic (Service Layer)
Manages DB connection pools, transactions
Handles sessions, authentication, authorization

This is the “original definition.” And at this point, Frontend/Backend was a layer division occurring within the WAS. If HTML was generated with JSP or Servlet, it was Frontend; if data was processed from the DB with Service/DAO, it was Backend. Both ran within the same Tomcat.

So, is WAS divided into Frontend and Backend?

This is the core question. To conclude — “In the past, it was a layer division within WAS, but now WAS itself has branched into two types” is the most accurate answer.

Why did this branching occur?

Two things happened simultaneously from the mid-2010s.

The first is the rise of SPA (Single Page Application). With the advent of React, Vue, and Angular, the frontend began to operate independently in the browser. The server no longer rendered HTML but only provided JSON APIs, and the browser drew the screen itself.

The second is the re-emergence of SSR (Server-Side Rendering). To solve SPA’s SEO and initial loading issues, Node.js-based Next.js, Nuxt.js like frameworks began to generate HTML on the server again.

At this second point, the concept of a “Frontend-specific WAS” emerged.

Modern 3-Layer Division


Category	Role	Representative Technology
Web Server	Serving Static Resources	Nginx, Apache, CDN
Frontend WAS	Dynamically generating HTML with SSR	Next.js, Nuxt.js, Remix
Backend WAS	Business Logic + DB	Spring Boot, Django, Rails

In other words, the question “Can WAS be divided into Frontend and Backend?” as you asked, is most accurately understood in a modern sense as “Two types of servers have emerged within the WAS category.” It’s not that the internal structure of WAS split into two, but rather that the types of servers that can be called WAS have increased to two.

Simple Analogy — A Restaurant

An analogy of the three servers to a restaurant makes it easier to understand.

Web Server = The menu board at the entrance. It quickly displays unchanging information.
Frontend WAS(SSR) = The waiter. Takes the customer’s order, passes it to the kitchen, and returns a neatly organized order slip. (Responsible for UI assembly)
Backend WAS(API) = The kitchen. Performs the actual cooking (business logic) and retrieves ingredients (DB).

In traditional architecture, the waiter and kitchen were attached in one space. Now, they are separated and work independently. There are even many restaurants without waiters (SPA + API-only structure).

Actual Configuration Example

In modern cloud architecture, the configuration of a service is usually drawn like this.

[Browser]
    ↓ HTTPS
[CloudFront / Nginx]           ← Web Server (정적 자원)
    ↓
[Next.js on Node.js]           ← Frontend WAS (SSR)
    ↓ REST / GraphQL
[Spring Boot on Tomcat]        ← Backend WAS (API)
    ↓ JDBC
[PostgreSQL / MySQL]           ← Database

The point to note here is that each layer runs on different instances or containers. Even if the Frontend WAS dies, the Backend WAS remains alive, and vice versa. This is the flexibility of the MSA (Microservices Architecture) era.

⚠️ Three Common Misconceptions

First, “A React app itself is a WAS” — No. A React app is a JavaScript bundle that runs in the browser. Static resources built with Webpack or Vite are often served by Nginx. In this case, the Frontend is just a static file behind a Web Server, not a WAS.

Second, “Next.js is a Web Server” — No. When Next.js runs in SSR mode, it dynamically generates HTML for each request, making it clearly a WAS. However, if built in Static Export mode, it only produces static files, so those outputs can be hosted on a Web Server.

Third, “Nginx also handles API logic” — Misconception. Nginx acts as a reverse proxy to forward requests to the WAS, but it does not execute business logic itself. The logic is handled by the WAS behind it.

✅ Summary

The principle is still valid: The basic formula of Web Server = static, WAS = dynamic has not changed.
The scope of WAS has broadened: In modern times, WAS can be divided into two types: Frontend (SSR) layer and Backend (API) layer.
Criterion for judgment: It’s clear if you judge based on “Is code executed on the server for each request?”
Practical perspective: When drawing your service architecture, you can apply each component to one of the four categories: Web Server / Frontend WAS / Backend WAS / DB.

Ultimately, terminology broadens its scope with time. Rather than clinging to textbook definitions, it is much more practical to have a framework for thinking that distinguishes whether each layer is static or dynamic, and client-side code or server-side code.