DEV Community: Rohit Sharma

Forward Proxy vs Reverse Proxy vs API Gateways

Rohit Sharma — Tue, 23 Jun 2026 10:05:28 +0000

This is a very common confusion because Forward Proxy, Reverse Proxy, and API Gateway all sit "in the middle" of communication. The difference is who they represent and what additional functionality they provide.

1. Forward Proxy: A Forward Proxy sits in front of the client and acts on behalf of the client.

Client --> Forward Proxy --> Internet Server

The server thinks: "This request came from the proxy."

Example: Suppose your company blocks access to social media.

The company proxy can:

Allow/block websites
Cache responses
Hide your IP address
Log your traffic

Real-world examples: Company Proxies and VPN Servers

2. Reverse Proxy: A Reverse Proxy sits in front of the servers and acts on behalf of the servers.

Client --> Reverse Proxy --> Backend Servers

The client thinks: "I am talking to one server."

But behind the proxy, there may be many servers.

Example

Internet
    |
    v
NGINX
    |
    +--> App Server 1
    +--> App Server 2
    +--> App Server 3

Responsibilities:

Load balancing
SSL termination
Caching
Compression
Routing

Examples: Nginx

3. API Gateway: An API Gateway is a specialized reverse proxy for APIs and microservices.

Client
   |
   v
API Gateway
   |
   +--> User Service
   +--> Order Service
   +--> Payment Service

It does everything a reverse proxy does plus:

Authentication
Authorization
Rate limiting
API versioning
Request transformation
Response aggregation
Monitoring
API keys
Quotas

Why Definitions Sound Similar? Because all of them:

Receive requests
Forward requests
Return responses

The real difference is:

Question            Forward Proxy   Reverse Proxy   API Gateway
Represents whom?    Client          Server          Server/API
Sits in front of?   Clients         Servers         APIs/Microservices
Used by?            Internal users  Backend systems Microservices
Authentication?     Rare            Sometimes       Yes
Rate limiting?      Rare            Sometimes       Yes
Aggregation?        No              No              Yes

One-line way to remember

Forward Proxy → protects and represents clients.
Reverse Proxy → protects and represents servers.
API Gateway → a smart reverse proxy specifically for APIs and microservices.

API Gateway in System Design

Rohit Sharma — Tue, 23 Jun 2026 09:50:48 +0000

What is API Gateway?
An API Gateway is a server that sits between the client (web app, mobile app, frontend) and your backend services (microservices).

Instead of the client directly calling multiple services, it sends all requests to the API Gateway, and the gateway routes the request to the appropriate service.

Without API Gateway

Client
  |
  |-----> User Service
  |
  |-----> Product Service
  |
  |-----> Order Service
  |
  |-----> Payment Service

The client needs to know:

URLs of all services
Authentication mechanism of all services
Error handling of all services

This becomes difficult to manage.

With API Gateway

Client
   |
   |
API Gateway
   |
   |------> User Service
   |
   |------> Product Service
   |
   |------> Order Service
   |
   |------> Payment Service

Now the client only knows one URL: https://api.mycompany.com
Everything else is handled by the gateway.

Real-world Example Suppose you're building an e-commerce application.

Frontend needs:

Without Gateway

https://user.mycompany.com/login
https://product.mycompany.com/products
https://order.mycompany.com/orders
https://payment.mycompany.com/pay

With Gateway

https://api.mycompany.com/login
https://api.mycompany.com/products
https://api.mycompany.com/orders
https://api.mycompany.com/pay

The gateway routes internally.

Responsibilities of API Gateway

1. Request Routing

/api/users/*      -> User Service
/api/orders/*     -> Order Service
/api/products/*   -> Product Service

2. Authentication: Instead of every service validating JWT, only API Gateway does that.

Client
   |
 JWT Token
   |
API Gateway
   |
Valid Token?
   |
Yes -> Forward
No  -> Return 401

3. Authorization
4. Rate Limiting
5. Load Balancing
6. Caching
7. Logging
8. SSL Termination
9. Response Aggregation

Trailing and Non Trailing Slash in Nginx

Rohit Sharma — Tue, 23 Jun 2026 07:22:42 +0000

Most tricky part of Nginx: The trailing slash behavior in proxy_pass is one of the most confusing parts of Nginx. Once you understand one rule, it becomes easy

There are 2 Cases:

CASE 1: proxy_pass WITHOUT trailing slash

location /api/ {
    proxy_pass http://localhost:3000;
}

notice

http://localhost:3000
                     ↑
                 no slash

request

http://localhost/api/users

What Nginx sends to backend

http://localhost:3000/api/users

The entire original URI is preserved.

CASE 2: proxy_pass WITH trailing slash

location /api/ {
    proxy_pass http://localhost:3000/;
}

notice

http://localhost:3000/
                     ↑
                  slash

request

http://localhost/api/users

what backend receives

http://localhost:3000/users

Nginx removes the matched location (/api/) and replaces it with /

VISUAL REPRESENTATION (Without Slash)

Client:
    /api/users

location:
    /api/

proxy_pass:
    http://localhost:3000

Result:
    http://localhost:3000/api/users

VISUAL REPRESENTATION (With Slash)

Client:
    /api/users

location:
    /api/

proxy_pass:
    http://localhost:3000/

Result:
    http://localhost:3000/users

Why? Because internally Nginx does:

NO SLASH

backend_url + original_uri

http://localhost:3000
+
/api/users

=
http://localhost:3000/api/users

WITH SLASH

replace(location_prefix, proxy_pass_uri)

/api/users
↓ remove /api/
/users

prepend /
↓

http://localhost:3000/users

In simpler words, think of it as:

No slash (Keep the original URI)
Slash (Replace the matched prefix)

Nginx does NOT look at whether /api/ exists in the request and remove it automatically.

It only removes the matched location prefix when proxy_pass contains a URI part (a trailing slash or some path).

Understanding the both cases carefully
Case 1: No trailing slash

location /api/ {
    proxy_pass http://localhost:3000;
}

notice

proxy_pass = http://localhost:3000

There is:

scheme → http
host → localhost
port → 3000
URI part → ❌ NONE

Because there is no URI part, Nginx simply forwards the entire original URI.

Request : /api/users

Nginx does

http://localhost:3000
+
/api/users
=
http://localhost:3000/api/users

No replacement happens.

CASE 2: TRAILING SLASH

location /api/ {
    proxy_pass http://localhost:3000/;
}

notice

proxy_pass = http://localhost:3000/

There is / at end which is a URI part

As there is / in the URI part

scheme → http
host → localhost
port → 3000
URI part → /

Now Nginx switches to replacement mode.

Request: /api/users
Matched location: /api/
Remaining: users
Result: http://localhost:3000/users

Why does / count as a URI?

Because internally Nginx parses:

http://localhost:3000

as:

host = localhost
port = 3000
uri = NULL

but

http://localhost:3000/

as:

host = localhost
port = 3000
uri = /

That tiny / changes the algorithm completely.

Internal logic (simplified). Nginx does something like:

if (proxy_pass_contains_uri) {
    replace_location_prefix();
}
else {
    append_original_uri();
}

OR IN SOME SIMPLE WORDS, How Nginx actually thinks

Did proxy_pass contain a URI part?
            |
      +-----+-----+
      |           |
     NO          YES
      |           |
Keep URI      Replace matched location prefix
as-is         with proxy_pass URI

Foward Proxy / Reverse Proxy / SSL TLS Termination

Rohit Sharma — Tue, 23 Jun 2026 02:23:49 +0000

What is a proxy?
A proxy is an intermediary server that receives a request, forwards it elsewhere, receives the response, and sends it back.

Forward Proxy (Represents the Client)
Sits in front of client and hides the client from servers. Server cannot see the real client

 Client ---> Forward Proxy ---> Server

Imagine your company blocks access to YouTube.

Instead of

Laptop ---> youtube.com

You do

Laptop ---> Corporate Proxy ---> youtube.com

The proxy makes the request on your behalf. The server sees request coming from Proxy IP not from your laptop.

Real Example School/college proxy, Corporate internet proxy, VPNs.

When you connect to a VPN:

Your PC ---> VPN Server ---> Google

Google sees VPN IP instead of of your original IP.

Why use forward proxy?

Privacy: Hides the Client IP due to which Websites can't directly identify the client.
Content Filtering: companies block some websites at the office network
Caching: 100 employees request same file, without proxy 100 requests would go to internet. With proxy first request would go to internet and next 99 would be server from proxy cache.

Reverse Proxy (Represents the Server)
Sits in front of server and hides the server from client. Client Cannot see the real server

Client ---> Reverse Proxy ---> Server

Suppose you have multiple servers i.e. Server 1, Server 2, Server 3 etc and you don't want clients to know about these servers. In this case we need to setup reverse proxy and, proxy decides which server gets the request.

Client
   |
   v
Reverse Proxy
   |
   +----> Server1
   |
   +----> Server2
   |
   +----> Server3

Example: When you open amazon.com your request doesn't directly hit an application server. It usually go to

Browser
   |
Load Balancer / Reverse Proxy
   |
Backend Servers

Real Example: Nginx in front of Node.js servers

Why use Reverse Proxy?

Load Balancing
SSL/TLS Termination: Without reverse proxy every backend server, decrypts https, with reverse proxy setted up, it handles the encryption while backend focus upon the business logic. Don't worry if SSL/TLS is not clear to you, at end of this article we have detailed explanation of SSL/TLS.
Hides Internal Servers: Client never knows the servers, which eventually improves the security
Caching: For expensive endpoints, Reverse proxy stores response for the future requests.

Now Let's Boost your understanding of SSL(Secure Socket Layer) and TLS(Transport layer Security):

SSL and TLS both are same terms, name SSL was used in earlier days and now its new name TLS is being used.

Detailed flow of TLS

Step 1: Browser sends a request

https://api.company.com/users

Step 2: Reverse proxy i.e. Nginx here, receives HTTPS.

Browser
   |
HTTPS
   |
Nginx

Step 3: Nginx decrypts request.

Encrypted Request
       ↓
Decrypt
       ↓
Plain HTTP Request

Step 4: Nginx forwards request.

GET /users

to backend

Browser
   |
HTTPS
   |
Nginx
   |
HTTP
   |
Node Server

Step 5: Backend processes business logic.

app.get('/users', () => {
   return users;
});

Step 6: Response returns. Nginx encrypts before sending to browser.

Node
   |
HTTP
   |
Nginx
   |
HTTPS
   |
Browser

Why Do This?

1. Less CPU Usage: As Encryption/decryption is expensive.

Without termination:

100 servers
100 TLS handshakes
100 certificate configs

With termination: Reverse proxy handles TLS. Backend servers focus on business logic.

2. Easier Certificate Management

Without reverse proxy: Nightmare to maintain certificates.

Certificate on Server 1
Certificate on Server 2
Certificate on Server 3

With reverse proxy: Certificate to be maintained only on Nginx. Renew once.

3. Simpler Backend Code: Backend doesn't care about HTTPS. It Just process requests.

app.get('/users', ...)

Real MAANG Architecture

User
  |
HTTPS
  |
Load Balancer
  |
HTTPS
  |
Reverse Proxy
  |
HTTP/gRPC
  |
Microservices

User
  |
HTTPS
  |
Load Balancer (TLS Termination)
  |
HTTP
  |
Services

Often the cloud load balancer itself performs TLS termination.

Important note on SSL/TLS termination: SSL/TLS termination means a reverse proxy or load balancer handles HTTPS encryption/decryption on behalf of backend servers. The client communicates securely with the proxy using HTTPS, the proxy decrypts the request and forwards it to backend services, typically over HTTP or an internal secure network. This reduces CPU overhead on application servers and centralizes certificate management.

The benefit of TLS termination is that:

1,000 Clients
      |
      v
Reverse Proxy
      |
      v
100 Backend Servers

The 100 backend servers do not perform those 1,000 TLS handshakes.
The reverse proxy performs them and forwards the already-decrypted requests internally.That's where the CPU savings come from. As "TLS connection terminates at the reverse proxy instead of the application server so its termed as TLS termination.

Rest & Restfulness API Design Principles

Rohit Sharma — Thu, 18 Jun 2026 01:43:54 +0000

Representational State Transfer is an architectural style used for designing the network applications. Instead of relying on complex protocols REST relies on standard web protocols like HTTP to enable communication between clients and server.

If Definition seems complex to you, no worries let's breakdown the word
REST = Representation State Transfer

Suppose you have a user resource:

/users/7

This actual resource, exists on the server i.e. database row containing all the information about user with id 7.

REPRESENTATION The server doesn't send the actual database row. It sends just a representation of the resource.

{
 "id":7,
 "name":"Rohit"
}

This JSON is a representation of the user's current state.

STATE TRANSFER When the client requests

GET users/7

The server transfers representation of this resource's state to the client.

   Server State
        ⬇️
JSON Representation
        ⬇️
Transferred over HTTP
        ⬇️
      Client

That's where the term Representational state transfer comes from.

Main Idea behind REST: It operates on stateless communication which means that each request from client contains all the necessary information and server does not store any session data between requests. This makes REST very scalable, reliable and easy to implement.

Why REST matters?

Simplicity & Scalability: Rest is build on standard HTTP protocols like GET, PUT, POST and DELETE making it easy to understand and implement. Because REST follow stateless architecture it scales efficiently, allowing multiple servers to handle requests without maintaining session data.
Interoperability: REST APIs are platform independent which means they can be consumed by clients running on different devices, different Operating Systems and implemented in different programming languages. Whether its a mobile application or web application, REST can be used everywhere.
Efficiency: By leveraging caching REST can introduce lower latency which contribute towards enhancing performance.

app.get(/product/:id, async(req,res) =>{
  product = await productService.getProduct(req.params.id);
  res.set('Cache-Control', 'public, max-age=300');  //this tells clients, browsers, CDNs, reverse proxies & API Gateways: You may cache this response for 300 seconds
  res.json(product);
})

REST's cachebility constraint is typically implemented by sending HTTP cache headers such as Cache-Control, ETag or expires. These headers allow clients to cache responses, reducing the latency and backend loads.

RESTful API Design Principles

Not every API using HTTP is RESTful, A RESTful API is an API that follows REST principles correctly. So, below are the design principles of a perfect REST API:

1.Resource-Based URLs: Resources should be nouns, not verbs.

❌BAD

GET /getUsers
POST /createUser
DELETE /deleteUser/101

✅GOOD

GET /users
POST /users
DELETE /users/101

2.Use HTTP methods properly

GET    /users       -> Fetch users
POST   /users       -> Create user
PUT    /users/101   -> Replace user
PATCH  /users/101   -> Update user
DELETE /users/101   -> Delete user

3.Statelessness: Every request should contain all information needed. Server should not remember previous requests.

GET /orders
Authorization: Bearer JWT_TOKEN

//The JWT carries user identity. Server doesn't need session memory.

4.Client-Server Separation: Frontend and backend are independent. Frontend can change without changing backend
5.Cacheable Responses: Frequently accessed data can be cached, which eventually reduces latency and improves performance.

Example of perfect RESTful User API

GET    /users
GET    /users/101
POST   /users
PUT    /users/101
PATCH  /users/101
DELETE /users/101

This is considered RESTful because:

✅ Resources are nouns
✅ Correct HTTP methods used
✅ Stateless
✅ Consistent URL design