Debug School: rakesh kumar

Different kind of prompt used by Spring AI

rakesh kumar — Fri, 27 Mar 2026 06:17:45 +0000

Main kinds of prompts Spring AI helps you make
A. System prompt

This tells the model how to behave.

Examples:

“You are a helpful banking assistant.”
“Answer in simple English.”
“Do not return unsafe medical advice.”

Role: controls tone, style, rules, and boundaries. Spring AI docs say system messages are generated by the system to guide the conversation.

B. User prompt

This is the actual question or request from the user.

Examples:

“What is compound interest?”
“Summarize this document.”
“Translate this to Hindi.”

Role: carries the direct input to the model. Spring AI identifies user messages as the direct inputs from the user.

C. Multi-message chat prompt

This combines multiple messages together, usually:

one or more system messages
one user message
sometimes previous conversation messages

Role: gives the model better context than a single plain text prompt. Spring AI’s prompt model is message-based, not just one raw string.

D. Template prompt / parameterized prompt

This is a prompt with placeholders like {name}, {topic}, {question}.

Examples:

“Explain {topic} to a beginner.”
“Write an email to {customerName} about {issue}.”

Role: makes prompts reusable and dynamic. The docs note that prompts often contain placeholders substituted at runtime. The prompt docs also compare this to a view template or SQL with placeholders.

E. External file prompt

You can keep prompts outside Java code in template files instead of hardcoding them. That makes them reusable and easier to version and maintain. Your screenshot mentions .st, .mustache, and .ftl, and Spring AI’s docs show PromptTemplate rendering support, including the default StPromptTemplate based on StringTemplate.

F. RAG prompt

This is used when you want the model to answer using retrieved context from documents or a vector database. Spring AI’s RAG support lets you customize a PromptTemplate that merges the user query with retrieved context, and the docs specify placeholders such as query and question_answer_context.

G. Memory-aware prompt

LLMs are stateless by default, so Spring AI adds chat memory features to carry useful prior context into later interactions. This helps create prompts that include conversation context without you manually rebuilding it each time.

2) Why these prompt types matter

Different prompt types solve different problems:

System prompt → behavior and rules
User prompt → actual request
Template prompt → reuse and dynamic input
RAG prompt → answer from documents/context
Memory-aware prompt → continue a conversation naturally

That is why Spring AI is useful: it gives structure around prompt creation instead of making you manually assemble raw HTTP JSON every time. ChatClient builds prompt parts fluently, and Advisors can add memory, retrieved documents, and more advanced behavior.

3) Coding examples

These examples are written in the normal Spring AI style and may need small adjustment depending on your exact Spring AI version.

Example 1: Simple system prompt + user prompt

@RestController
@RequestMapping("/ai")
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    @GetMapping("/explain")
    public String explain(@RequestParam String topic) {
        return chatClient.prompt()
                .system("You are a Java teacher. Explain in simple English.")
                .user("Explain this topic for a beginner: {topic}")
                .param("topic", topic)
                .call()
                .content();
    }
}

What happens here

.system(...) creates a system prompt
.user(...) creates a user prompt
.param(...) fills the template placeholder dynamically

This matches the docs’ message-based prompt model and runtime placeholder substitution.

Example 2: Reusable template prompt

@Service
public class EmailPromptService {

    private final ChatClient chatClient;

    public EmailPromptService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String generateEmail(String customerName, String issue) {
        return chatClient.prompt()
                .system("You are a professional customer support writer.")
                .user("""
                      Write a polite support email to {customerName}.
                      The issue is: {issue}
                      Keep the tone professional and short.
                      """)
                .param("customerName", customerName)
                .param("issue", issue)
                .call()
                .content();
    }
}

Why this is useful

Same prompt structure, different values. That is the main idea of template prompts. Spring AI docs explicitly describe placeholders being replaced based on user requests or application code.

Example 3: Prompt from external template file idea

Suppose you keep a prompt file like:

src/main/resources/prompts/greeting.st

Hello, my name is {name}. Can you greet me back nicely?

Then your code can render and send it through Spring AI. A simplified example:

@Service
public class GreetingService {

    private final ChatClient chatClient;

    public GreetingService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String greet(String name) {
        String template = "Hello, my name is {name}. Can you greet me back nicely?";

        return chatClient.prompt()
                .user(template)
                .param("name", name)
                .call()
                .content();
    }
}

Spring AI supports prompt templating and documents PromptTemplate; for RAG templates it uses StPromptTemplate by default, based on StringTemplate.

Example 4: RAG-style prompt

String answer = chatClient.prompt()
        .system("Answer only from the provided context. If unsure, say you do not know.")
        .user("""
              Question: {question}

              Context:
              {context}
              """)
        .param("question", "What is the refund policy?")
        .param("context", """
                Refunds are allowed within 7 days of purchase
                if the product has not been activated.
                """)
        .call()
        .content();

This is the basic idea behind a RAG prompt: merge the user query with retrieved context. Spring AI’s RAG docs describe custom templates that combine query and retrieved context for answering.

Example 5: Memory-aware chat idea

String response = chatClient.prompt()
        .system("You are a helpful assistant that remembers prior discussion context.")
        .user("Continue our last discussion and summarize the final decision.")
        .call()
        .content();

In real apps, chat memory is usually backed by Spring AI chat memory support, because LLMs are stateless by default and Spring AI adds memory abstractions to maintain useful context.

Very simple summary

Spring AI mainly helps you create these prompt types:

System prompts
User prompts
Multi-message prompts
Template prompts
External-file prompts
RAG prompts
Memory-aware prompts

So the big benefit is not just “send text to GPT.”
The real benefit is: Spring AI gives prompt structure, reuse, context, and maintainability inside a Spring Boot application

How Spring AI Simplifies REST API Integration in Modern Applications

rakesh kumar — Fri, 27 Mar 2026 05:30:34 +0000

Theory explanation
Why not call REST API directly from controller?
Main purpose of Spring AI interface
Why this helps in modern applications
Simple flow
Coding example

Theory explanation

In a normal Spring Boot project, you can call an AI provider directly with REST APIs.
That means your code builds HTTP requests, adds headers, sends JSON, handles authentication, parses responses, and manages retries by itself.

That works for small demos, but in modern applications it becomes repetitive and hard to maintain.

Spring AI simplifies this by putting a Spring-style abstraction layer between your application and the AI provider. Instead of writing low-level HTTP code everywhere, you work with higher-level APIs such as ChatClient, ChatModel, Prompt, and advisors. The Spring AI reference describes ChatClient as a fluent API for communicating with an AI model, where prompts are built from messages like user and system messages.

So the difference is:

REST API only = low-level transport and manual integration
Spring AI = structured, reusable, Spring-friendly AI integration built on top of provider APIs

Why not call REST API directly from controller?

Because controller should mainly handle:

incoming request
validation
response

If controller also manages:

AI API payloads
prompt structure
JSON parsing
retries
embeddings
vector DB lookup

then controller becomes overloaded.

Spring AI keeps the design cleaner.

Main purpose of Spring AI interface

It hides low-level HTTP complexity

You do not need to manually build every REST request.

Instead of this:

create URL
create headers
add API key
build JSON
send request
parse result

You can use a cleaner Spring-style approach.

It gives a Spring-friendly programming model

In Spring Boot, developers like:

dependency injection
beans
service classes
reusable configuration

Spring AI fits that style.

So AI feels like a normal Spring service, not like raw external API handling.

Example idea:

ChatClient
EmbeddingModel
PromptTemplate

These are easier to use in service classes.

It reduces vendor lock-in

Different providers have different request and response formats.

Without Spring AI:

OpenAI code looks one way
another provider looks different
switching providers means code change in many places

With Spring AI:

you work through a common abstraction
changing provider becomes easier

It supports AI-specific features, not just REST calling

AI integration is not just sending text over HTTP.

It often includes:

prompt templating
chat memory
embeddings
vector search
RAG flow
structured output
model options

REST API does not give these patterns automatically.

Spring AI provides structure for them.

It makes enterprise code cleaner

In small demo projects, direct REST calls are okay.

But in real applications:

chatbot
recommendation engine
support assistant
document Q&A
healthcare AI assistant

you need better architecture.

Spring AI helps separate:

controller
business logic
AI interaction
prompt layer
retrieval layer

That makes the project easier to scale.

Why this helps in modern applications

Cleaner code

Without Spring AI, you often repeat:

API URL handling
auth token or API key setup
request body creation
response parsing
provider-specific JSON mapping

Spring AI centralizes that interaction. Its model API is designed as a portable interface across providers, which makes the code cleaner and more maintainable.

Easier provider switching

If you call one provider directly using raw REST, your code usually becomes tightly coupled to that provider’s request and response format.

Spring AI’s Chat Model API is designed to be portable, so moving across supported providers requires fewer code changes than rewriting raw REST integration everywhere.

Prompt handling becomes structured

Modern AI apps need more than one plain input string. They need:

system instructions
user prompts
templates
placeholders
context injection

Spring AI supports prompts as structured message collections and supports prompt templating, which is much better than building JSON strings manually for each REST call.

Better support for advanced AI patterns

Modern applications often need:

chat memory
embeddings
RAG
tool calling
streaming responses

Spring AI supports these patterns directly through its APIs and advisors, which is far beyond “just send a REST request.”

Better fit with Spring Boot architecture

Spring developers prefer:

dependency injection
beans
service classes
configuration properties
starter-based setup

Spring AI fits naturally into that model. For example, the official docs provide Spring Boot starter-based configuration such as spring-ai-starter-model-openai, and the getting-started docs state support for Spring Boot 3.4.x and 3.5.x.

Simple flow

Direct REST approach

Controller → Service → Manual HTTP Client → AI Provider API

Spring AI approach

Controller → Service → ChatClient / ChatModel → AI Provider API

Spring AI still uses provider APIs underneath, but your application code stays much simpler.

Coding example

Below is a simple Spring Boot example using Spring AI with OpenAI-style integration.

1) Maven dependencies

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>YOUR_VERSION</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-model-openai</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

The official Spring AI OpenAI chat docs show spring-ai-starter-model-openai as the starter artifact.

2) application.properties

spring.ai.openai.api-key=YOUR_API_KEY
spring.ai.openai.chat.options.model=gpt-4o-mini

Spring AI provides Spring Boot auto-configuration for the OpenAI chat client through properties under the Spring AI namespace.

3) Service class

package com.example.demo.service;

import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;

@Service
public class AiService {

    private final ChatClient chatClient;

    public AiService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String explainTopic(String topic) {
        return chatClient.prompt()
                .system("You are a helpful Java and Spring expert. Explain in simple English.")
                .user("Explain this topic in a modern application context: {topic}")
                .param("topic", topic)
                .call()
                .content();
    }
}

This uses ChatClient’s fluent API to build a prompt from system and user messages, with runtime parameters. That is exactly the sort of prompt-building model described in the official docs.

4) REST controller

package com.example.demo.controller;

import com.example.demo.service.AiService;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class AiController {

    private final AiService aiService;

    public AiController(AiService aiService) {
        this.aiService = aiService;
    }

    @GetMapping("/api/explain")
    public String explain(@RequestParam String topic) {
        return aiService.explainTopic(topic);
    }
}

Now your application exposes a normal REST endpoint, but internally it uses Spring AI rather than a manually coded HTTP call to the model provider.

How to integrate AI models into Spring Boot applications using Spring AI

rakesh kumar — Fri, 27 Mar 2026 03:39:18 +0000

What is Spring AI?
Spring AI Architecture
Purpose of Spring AI
Role of Spring AI
How Flow Works
Common Questions (with Answers)

What is Spring AI?

Spring AI is a framework that helps developers integrate AI models (like GPT, LLMs, embeddings, etc.) into Spring Boot applications easily.

Instead of manually calling AI APIs and handling complexity, Spring AI provides:

Clean Java-based abstraction
Easy integration with AI providers (OpenAI, Azure, etc.)
Support for chat, embeddings, vector DB, prompt templates

👉 In simple words:

Spring AI = Bridge between Spring Boot apps and AI models

🎯

Spring AI Architecture

How Spring AI Works

Users give input to Spring Boot REST controller.
Spring AI processes the user input using Prompt Templates or ChatClient (to call LLM)
ChatClient connects to external AI providers (OpenAI, Ollama, etc.)
And response is returned to the Spring Boot app and sent back to the user . Multi-Provider Support: Spring AI framework supports connecting to multiple LLM providers like

OpenAI (ChatGPT)
Azure OpenAI
Hugging Face (Transformers)
Ollama (for local models)

Chat Client API: Standardizes communication with LLMs using a fluent API, regardless of provider differences.

Prompt Templates: Developers can define dynamic prompts with variables using Spring Expression Language (SpEL).

Embedding and Vector Store Integration: Spring AI supports converting text into embeddings like numeric vector and storing them in vector databases like PostgreSQL with pgvector.

Structured Outputs ( Like POJO Mapping): Spring AI model output (like JSON) directly to the Java POJOs class using annotations and converters.

Features of Spring AI

Purpose of Spring AI

The main purpose is to simplify AI integration in enterprise Java applications.

Key Goals:

Reduce boilerplate code for AI API calls
Provide standardized APIs (like Spring Data, Spring MVC)
Enable production-ready AI apps
Support scalable and maintainable architecture

🧩

Role of Spring AI

AI Integration Layer Connects your Spring Boot app with AI models Handles API calls, authentication, retries
Abstraction Provider You don’t write raw HTTP calls Use simple Java interfaces
Prompt Management Helps structure prompts cleanly Supports templates
Data Handling (Vector + Embeddings) Store & search semantic data Used in RAG (Retrieval-Augmented Generation)
Enterprise Enablement Works with microservices Secure, scalable, production-ready 🏗️ Architecture (Colorful + Labeled Representation)

How Flow Works

User sends request → Frontend
Request hits → Spring Boot Controller
Service calls → Spring AI layer
Spring AI sends request → AI Model (GPT)
AI response → back to Spring Boot → UI

❓

Common Questions (with Answers)

Why use Spring AI instead of direct API calls?

👉 Because it reduces complexity, gives structure, and is production-ready.

Can Spring AI work with Laravel backend?

👉 No directly. Spring AI is for Java ecosystem.
For Laravel, you use OpenAI SDK or HTTP APIs manually.

Is Spring AI suitable for microservices?

👉 Yes, very suitable. You can create:

AI microservice
Chat service
Recommendation engine

What features does Spring AI provide?

Chat completion
Embeddings
Prompt templates
Vector DB integration
RAG support

When should you choose Spring AI?

👉 Choose it when:

Your backend is Spring Boot
You need enterprise AI integration
You want clean, scalable architecture

When NOT to use Spring AI?

👉 Avoid if:

Your backend is Laravel/PHP
Small project (simple API call enough)
🔥 Final Simple Summary

Purpose: Simplify AI integration
Role: Bridge Spring Boot ↔ AI Models
Benefit: Clean, scalable, enterprise-ready AI apps

Reference
utube

How to Build a Simple AI Question Answer App with LangChain

rakesh kumar — Tue, 17 Mar 2026 10:35:28 +0000

Direct LLM call

result = llm.invoke("What is generative AI?")

Chain call

chain = prompt | llm
response = chain.invoke({"input":"Can you tell me about Langsmith?"})

Chain with output parser

chain = prompt | llm | output_parser
response = chain.invoke({"input":"Can you tell me about Langsmith?"})

Why use chain?

We use a chain to connect multiple steps in one flow.

For example:

first step = format the prompt

second step = send it to LLM

third step = parse the output

So instead of writing everything separately, chain makes it clean, reusable, and easy to manage.

Simple sentence:

Chain is used to join prompt + model + parser into one pipeline.

Why use StrOutputParser?

When you call:

response = chain.invoke(...)

without parser, the output is usually an AIMessage object.

That means response contains:

content

metadata

extra model information

But many times we only need the final text.

So StrOutputParser() converts the output into a plain string.

Simple sentence:

StrOutputParser is used to extract only text from the model response.

Difference between both chains

Chain 1
chain = prompt | llm

Output type:

AIMessage
Chain 2

chain = prompt | llm | output_parser

Output type:

str
Why use second chain?

Because it gives clean text output, which is easier to:

store in database

show in UI

pass to next function

20 Important Questions Based on Your Screenshot

Subjective Questions

What is the purpose of load_dotenv() in this code?

Answer:
load_dotenv() loads environment variables from the .env file into Python, so secrets like API keys can be used safely.

Why do we store OPENAI_API_KEY in environment variables?

Answer:
Because API keys are sensitive data. Keeping them in environment variables is safer than writing them directly in code.

What is the use of ChatOpenAI(model="gpt-4o")?

Answer:
It creates an LLM object that allows us to communicate with the OpenAI chat model.

What does llm.invoke("What is generative AI?") do?

Answer:
It sends the input question to the model and gets a response back.

What is ChatPromptTemplate?

Answer:
ChatPromptTemplate helps us create structured prompts using system messages and user messages.

Why do we use a system message in prompt template?

Answer:
A system message sets the behavior of the model, like telling it to act as an AI engineer or teacher.

Why do we use {input} inside the prompt template?

Answer:
{input} is a variable placeholder. It lets us send different user questions dynamically.

Why do we use prompt | llm?

Answer:
It creates a chain where the prompt is first prepared and then sent to the language model automatically.

Why do we use StrOutputParser()?

Answer:
Because the LLM normally returns an AIMessage object, and StrOutputParser() converts that into plain text.

What is the main benefit of using chains in LangChain?

Answer:
Chains reduce manual coding and make the workflow modular, readable, and reusable.

Objective Questions

load_dotenv() is used to:

Answer: Load variables from .env file.

os.getenv("OPENAI_API_KEY") is used to:

Answer: Read the API key from environment variables.

The output type of prompt | llm is generally:

Answer: AIMessage

The output type of prompt | llm | StrOutputParser() is generally:

Answer: string

ChatPromptTemplate.from_messages() is used to:

Answer: Create prompt structure using system and human messages.

LANGCHAIN_TRACING_V2="true" is used for:

Answer: Tracking and monitoring LangChain execution.

The symbol | in LangChain is used to:

Answer: Combine components into a chain.

MCQ Questions

Which function loads environment variables from a .env file?

A. getenv()
B. load_dotenv()
C. setenv()
D. read_env()

Answer: B. load_dotenv()

What does StrOutputParser() return?

A. JSON object
B. Dictionary
C. Plain text string
D. AIMessage object

Answer: C. Plain text string

Why is prompt | llm | output_parser better than only prompt | llm in many cases?

A. It increases API speed
B. It converts response into plain text
C. It removes API key
D. It changes model version

Answer: B. It converts response into plain text

What is the role of PromptTemplate in this code?

A. To create database models
B. To define structured prompt text for the LLM
C. To validate JSON request
D. To start Flask server

Answer: B. To define structured prompt text for the LLM

Which of the following is one of the prompt keys in the prompts dictionary?

A. student_details
B. recommendation
C. save_recipe
D. database_query

Answer: B. recommendation

What is checked in this block? if llm is None: return jsonify({"error": "LLM is not available"}), 500

A. Whether query is empty
B. Whether prompt is missing
C. Whether language model instance is available
D. Whether JSON is valid

Answer: C. Whether language model instance is available

What does status code 500 mean here?

A. Data created successfully
B. Redirect response
C. Internal server error
D. Unauthorized user

Answer: C. Internal server error

What is created by this line?

chains = {key: prompts[key] | llm for key in selected_chains}

A. A database connection
B. A dictionary of runnable chains for selected prompts
C. A list of user queries
D. A JSON response

Answer: B. A dictionary of runnable chains for selected prompts

What does the | operator do in this line?

prompts[key] | llm

A. Performs bitwise OR
B. Joins prompt template with LLM into a pipeline/chain
C. Compares two values
D. Converts string to JSON

Answer: B. Joins prompt template with LLM into a pipeline/chain

Why is RunnableParallel(chains) used?**

A. To execute all selected chains one after another very slowly
B. To run multiple selected chains in parallel
C. To save results in database
D. To validate prompt variables

Answer: B. To run multiple selected chains in parallel

What does this line do?

results = parallel_chain.invoke({"query": query})

A. Deletes the query
B. Executes the chains using the given query input
C. Stops the LLM
D. Creates a new route

Answer: B. Executes the chains using the given query input

What is the main purpose of this loop?

for key, value in results.items():

A. To create database tables
B. To process each chain output one by one
C. To remove invalid prompts
D. To sort the JSON request

Answer: B. To process each chain output one by one

Why is this line used?

content = value.content if hasattr(value, "content") else str(value)

A. To check whether output has a content attribute and extract text safely
B. To delete content from result
C. To convert list into dictionary
D. To validate selected chains

Answer: A. To check whether output has a content attribute and extract text safely

Extra Important Interview Questions From This Screenshot

Here are some more commonly asked short questions you can revise:

Why not call the model directly every time?

Because direct model calls are fine for simple tasks, but chains are better for structured and reusable workflows.

Why use prompt templates instead of raw strings?

Because prompt templates are dynamic, cleaner, and easier to reuse.

What happens if we do not use output parser?

We get a model response object like AIMessage, not just plain text.

When is StrOutputParser very useful?

It is useful when you want only final text for display, saving, or passing to another function.

Why is chain more scalable?

Because later you can add memory, retrievers, tools, parsers, and multiple steps easily.

One-line easy revision

LLM gives response

Prompt template formats input

Chain connects steps

StrOutputParser extracts plain text

How to apply Persistent Login to Secure Sessions in Rust

rakesh kumar — Fri, 06 Mar 2026 10:35:17 +0000

Normally in web applications there are two types of login systems.

Session Login (Normal Login)

User logs in → session cookie created → session stored in server.

Problem:

If browser closes → session expires

If server restarts → session lost

User must login again

Persistent Login (Remember Me)

Persistent login allows:

User logs in → system stores secure token in database + cookie

Even if:

browser closes

session expires

server restarts

User can still be automatically logged in.

So the purpose of persistent login is:

Improve user experience

Reduce repeated login

Maintain security

Allow long-term authentication safely

Add security env vars
Add security env vars: SESSION_KEY, SESSION_TTL_HOURS, SESSION_SECURE_COOKIE.

SESSION_KEY=replace-with-32-byte-random-secret
SESSION_TTL_HOURS=24
# In production behind HTTPS set true. Local HTTP dev can stay false.
SESSION_SECURE_COOKIE=false

Read and validate those env vars into AppConfig fields:
src/config.rs
Read and validate those env vars into AppConfig fields:

session_ttl_hours session_secure_cookie

pub session_ttl_hours: i64,
pub session_secure_cookie: bool,

   let session_ttl_hours = env::var("SESSION_TTL_HOURS")
            .ok()
            .and_then(|v| v.parse::<i64>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(24);

        // Keep local dev usable on HTTP, default secure in non-local environments.
        let inferred_local = bind_addr.contains("127.0.0.1") || bind_addr.contains("localhost");
        let session_secure_cookie = env::var("SESSION_SECURE_COOKIE")
            .ok()
            .map(|v| {
                let lower = v.trim().to_ascii_lowercase();
                lower == "1" || lower == "true" || lower == "yes" || lower == "on"
            })
            .unwrap_or(!inferred_local);

        Self {
            app_name,
            bind_addr,
            database_url,
            session_ttl_hours,
            session_secure_cookie,
        }

full code

use std::env;

#[derive(Clone, Debug)]
pub struct AppConfig {
    pub app_name: String,
    pub bind_addr: String,
    pub database_url: String,
    pub session_ttl_hours: i64,
    pub session_secure_cookie: bool,
}

impl AppConfig {
    pub fn from_env() -> Self {
        let app_name = env::var("APP_NAME").unwrap_or_else(|_| "Rust CRUD Dashboard".to_string());
        let bind_addr = env::var("APP_BIND").unwrap_or_else(|_| "127.0.0.1:8080".to_string());
        let database_url = env::var("DATABASE_URL")
            .unwrap_or_else(|_| "mysql://root:@127.0.0.1:3306/rust_crud".to_string());
        let session_ttl_hours = env::var("SESSION_TTL_HOURS")
            .ok()
            .and_then(|v| v.parse::<i64>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(24);

        // Keep local dev usable on HTTP, default secure in non-local environments.
        let inferred_local = bind_addr.contains("127.0.0.1") || bind_addr.contains("localhost");
        let session_secure_cookie = env::var("SESSION_SECURE_COOKIE")
            .ok()
            .map(|v| {
                let lower = v.trim().to_ascii_lowercase();
                lower == "1" || lower == "true" || lower == "yes" || lower == "on"
            })
            .unwrap_or(!inferred_local);

        Self {
            app_name,
            bind_addr,
            database_url,
            session_ttl_hours,
            session_secure_cookie,
        }
    }
}

Apply session middleware hardening:
Apply session middleware hardening:

custom cookie name
cookie_secure(...)
cookie_http_only(true)
session_lifecycle(PersistentSession...session_ttl...)
safer SESSION_KEY handling (no fixed default secret)

src/main.rs

Apply session middleware hardening:

custom cookie name
cookie_secure(...)
cookie_http_only(true)
session_lifecycle(PersistentSession...session_ttl...)
safer SESSION_KEY handling (no fixed default secret)

      if valid {
            session.renew();

   if valid {
            session.renew();
            session
                .insert("username", user.username.clone())
                .map_err(error::ErrorInternalServerError)?;
            session
                .insert("user_id", user.id)
                .map_err(error::ErrorInternalServerError)?;
            session
                .insert("role", role.clone())
                .map_err(error::ErrorInternalServerError)?;
            println!("[login] session_set username={}", user.username);
            let response = ApiResponse {
                message: "Login successful".to_string(),
                data: AuthUser {
                    username: user.username,
                    role,
                },
            };
            return Ok(HttpResponse::Ok().json(response));
        }

On successful login, call session.renew() before inserting session values to reduce session fixation
src/handlers/auth.rs

use actix_session::{
    config::{PersistentSession, TtlExtensionPolicy},
    storage::CookieSessionStore,
    SessionMiddleware,
};
use actix_web::{
    cookie::{time::Duration, Key, SameSite},
    web, App, HttpServer,
};

    let session_key = std::env::var("SESSION_KEY").unwrap_or_else(|_| {
        eprintln!("[startup] SESSION_KEY is missing; generating ephemeral key for this process.");
        format!("{}{}", uuid::Uuid::new_v4(), uuid::Uuid::new_v4())
    });
    let mut session_key_bytes = session_key.into_bytes();
    if session_key_bytes.len() < 32 {
        session_key_bytes.resize(32, b'0');
    }

App::new()
            .app_data(state.clone())
            .wrap(cors)
            .wrap(
                SessionMiddleware::builder(CookieSessionStore::default(), key.clone())
                    .cookie_name("rust_crud_session".to_string())
                    .cookie_secure(cfg.session_secure_cookie)
                    .cookie_http_only(true)
                    .cookie_same_site(SameSite::Lax)
                    .session_lifecycle(
                        PersistentSession::default()
                            .session_ttl(Duration::hours(cfg.session_ttl_hours))
                            .session_ttl_extension_policy(TtlExtensionPolicy::OnEveryRequest),
                    )
                    .build(),
            )

full code

mod config;
mod db;
mod handlers;
mod layout;
mod middleware;
mod models;

use actix_cors::Cors;
use actix_files::Files;
use actix_session::{
    config::{PersistentSession, TtlExtensionPolicy},
    storage::CookieSessionStore,
    SessionMiddleware,
};
use actix_web::{
    cookie::{time::Duration, Key, SameSite},
    web, App, HttpServer,
};
use config::AppConfig;
use db::{init_pool, normalize_brand_model_rows, normalize_shop_rows, state_data, AppState};
use dotenvy::dotenv;

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    dotenv().ok();
    std::fs::create_dir_all("uploads/brand_models")?;
    std::fs::create_dir_all("uploads/insurance")?;
    std::fs::create_dir_all("uploads/pollution")?;
    std::fs::create_dir_all("uploads/rc_document")?;
    let cfg = AppConfig::from_env();
    let pool = init_pool(&cfg.database_url)
        .await
        .expect("Database connection failed");
    if let Err(err) = normalize_brand_model_rows(&pool).await {
        eprintln!("[startup] normalize_brand_model_rows failed: {err}");
    }
    if let Err(err) = normalize_shop_rows(&pool).await {
        eprintln!("[startup] normalize_shop_rows failed: {err}");
    }

    let state = state_data(AppState {
        pool,
        app_name: cfg.app_name.clone(),
    });

    let session_key = std::env::var("SESSION_KEY").unwrap_or_else(|_| {
        eprintln!("[startup] SESSION_KEY is missing; generating ephemeral key for this process.");
        format!("{}{}", uuid::Uuid::new_v4(), uuid::Uuid::new_v4())
    });
    let mut session_key_bytes = session_key.into_bytes();
    if session_key_bytes.len() < 32 {
        session_key_bytes.resize(32, b'0');
    }
    let key = Key::derive_from(&session_key_bytes);

    HttpServer::new(move || {
        let cors = Cors::default()
            .allowed_origin("http://localhost:5173")
            .allowed_origin("http://127.0.0.1:5173")
            .allowed_origin("http://localhost:5174")
            .allowed_origin("http://127.0.0.1:5174")
            .allowed_origin("http://localhost:8080")
            .allowed_origin("http://127.0.0.1:8080")
            .allowed_origin("http://localhost:8081")
            .allowed_origin("http://127.0.0.1:8081")
            .allow_any_header()
            .allow_any_method()
            .supports_credentials();

        App::new()
            .app_data(state.clone())
            .wrap(cors)
            .wrap(
                SessionMiddleware::builder(CookieSessionStore::default(), key.clone())
                    .cookie_name("rust_crud_session".to_string())
                    .cookie_secure(cfg.session_secure_cookie)
                    .cookie_http_only(true)
                    .cookie_same_site(SameSite::Lax)
                    .session_lifecycle(
                        PersistentSession::default()
                            .session_ttl(Duration::hours(cfg.session_ttl_hours))
                            .session_ttl_extension_policy(TtlExtensionPolicy::OnEveryRequest),
                    )
                    .build(),
            )
            .service(
                web::scope("/api")
                    .route("/login", web::post().to(handlers::login))
                    .route("/logout", web::post().to(handlers::logout))
                    .route("/home/vehicles", web::get().to(handlers::list_home_vehicle_cards_handler))
                    .service(
                        web::scope("")
                            .wrap(middleware::AuthMiddleware)
                            .route("/me", web::get().to(handlers::me))
                            .route("/dashboard", web::get().to(handlers::dashboard))
                            .service(
                                web::scope("")
                                    .wrap(middleware::require_roles(&["user"]))
                                    .route("/shops", web::get().to(handlers::list_shops_handler))
                                    .route("/shops", web::post().to(handlers::create_shop_handler))
                                    .route("/shops/{id}", web::get().to(handlers::get_shop_handler))
                                    .route("/shops/{id}", web::put().to(handlers::update_shop_handler))
                                    .route("/shops/{id}", web::delete().to(handlers::delete_shop_handler))
                                    .route("/vehicles", web::get().to(handlers::list_vehicles_handler))
                                    .route("/vehicles", web::post().to(handlers::create_vehicle_handler))
                                    .route(
                                        "/vehicles/upload-documents",
                                        web::post().to(handlers::upload_vehicle_documents_handler),
                                    )
                                    .route(
                                        "/vehicles/upload-partner-image",
                                        web::post().to(handlers::upload_vehicle_partner_image_handler),
                                    )
                                    .route("/vehicles/{id}", web::get().to(handlers::get_vehicle_handler))
                                    .route("/vehicles/{id}", web::put().to(handlers::update_vehicle_handler))
                                    .route("/vehicles/{id}", web::delete().to(handlers::delete_vehicle_handler))
                                    .route("/bookings/offline", web::post().to(handlers::save_offline_booking_handler))
                                    .route("/brand-models", web::get().to(handlers::list_brand_models_handler))
                                    .route("/brand-models", web::post().to(handlers::create_brand_model_handler))
                                    .route(
                                        "/brand-models/upload-images",
                                        web::post().to(handlers::upload_brand_model_images_handler),
                                    )
                                    .route(
                                        "/brand-models/upload-images/",
                                        web::post().to(handlers::upload_brand_model_images_handler),
                                    )
                                    .route(
                                        "/brand-model/upload-images",
                                        web::post().to(handlers::upload_brand_model_images_handler),
                                    )
                                    .route("/brand-models/{id}", web::get().to(handlers::get_brand_model_handler))
                                    .route("/brand-models/{id}", web::put().to(handlers::update_brand_model_handler))
                                    .route("/brand-models/{id}", web::delete().to(handlers::delete_brand_model_handler)),
                            ),
                    ),
            )
            .service(Files::new("/uploads", "./uploads"))
    })
    .bind(cfg.bind_addr)?
    .run()
    .await
}

Explanation

  let session_ttl_hours = env::var("SESSION_TTL_HOURS")
            .ok()
            .and_then(|v| v.parse::<i64>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(24);

alternative way

Same Logic in Beginner Style (Long Version)

This is the same code written in a more beginner friendly style.

use std::env;

fn main() {

    let value = env::var("SESSION_TTL_HOURS");

    let session_ttl_hours = match value {

        Ok(v) => {
            match v.parse::<i64>() {
                Ok(num) if num > 0 => num,
                _ => 24
            }
        }

        Err(_) => 24
    };

    println!("Session TTL = {}", session_ttl_hours);

}

Output is the same.

Understanding the Two-Layer Architecture of Actix Middleware: Transform vs Service

rakesh kumar — Fri, 06 Mar 2026 02:57:33 +0000

Why do we need both Transform and Service?
Why Actix Middleware Has Two Layers
Simple Real-World Analogy
What Transform Does
What Service Does
Core Difference
Visual Flow
Now Actual Actix Middleware Example
Step-by-Step Theory of the Code
Simple Understanding of Left and Right Body
What Happens at Runtime
Objective and MCQ

When developers start building custom middleware in Actix-Web, one concept creates the most confusion:

Why do we need both Transform and Service?

At first, it feels like both are doing the same job. But in reality, they have different responsibilities.

This is the core idea:

Transform creates the middleware

Service runs the middleware logic for each request

Once you understand this two-layer architecture, custom middleware becomes much easier.

Why Actix Middleware Has Two Layers

Actix middleware is designed in a flexible and reusable way.

A middleware must do two separate things:

Layer 1: Build the middleware

This happens when Actix sets up your app.

Layer 2: Process every incoming request

This happens every time a user calls an API route.

Because these are two different jobs, Actix separates them into:

Transform

Service

Simple Real-World Analogy

Think of a security system in an office.

Transform

This is the company that installs the security gate.

Service

This is the security guard who checks every person entering.

So:

the gate is created once

the checking happens again and again for each visitor

That is exactly how middleware works in Actix.

What Transform Does

Transform is the middleware factory.

Its job is:


receive the next inner service

wrap it

return a new middleware service

In simple words:

Transform prepares the middleware structure.

It does not handle every request directly.

Basic Theory of Transform

When you use:


.wrap(AuthMiddleware)

Actix calls Transform behind the scenes.

It says:

“Here is the inner service. Build a middleware around it.”

So Transform is like a constructor or factory.

What Service Does

Service is the real request processor.

Its job is:

receive each request

inspect it

decide whether to block or allow

call the next service if allowed

In simple words:

Service contains the actual middleware logic.

This is where you write code like:

check session

check token

check role

log request

measure response time

Core Difference

Transform

runs when middleware is attached

creates the middleware wrapper

setup layer

Service

runs on every request

executes middleware logic

runtime layer

Visual Flow

App Startup
   ↓
Transform runs
   ↓
Middleware service created
   ↓
-----------------------------
Each Client Request
   ↓
Service runs
   ↓
Check request
   ↓
Allow or block

A Very Simple Rust Example First

Before Actix, let us understand the idea using plain Rust thinking.

Factory example

struct GateFactory;

struct Gate;

impl GateFactory {
    fn build(&self) -> Gate {
        Gate
    }
}

impl Gate {
    fn check(&self, name: &str) {
        println!("Checking entry for {}", name);
    }
}

fn main() {
    let factory = GateFactory;
    let gate = factory.build();

    gate.check("Ashwani");
    gate.check("Ravi");
}

Output

Checking entry for Ashwani
Checking entry for Ravi

Explanation

GateFactory = like Transform

Gate = like Service

Factory creates the gate once.
Gate checks people many times.

That is the same idea as Actix middleware.

Now Actual Actix Middleware Example

Below is a basic custom authentication middleware.

It checks whether request contains header x-auth-token.

If header is missing:

return 401 Unauthorized

If present:

allow request to continue

Full Middleware Code

use std::future::{ready, Ready};
use std::rc::Rc;

use actix_web::{
    body::{EitherBody, MessageBody},
    dev::{forward_ready, Service, ServiceRequest, ServiceResponse, Transform},
    Error, HttpResponse,
};
use futures_util::future::LocalBoxFuture;

pub struct AuthMiddleware;

impl<S, B> Transform<S, ServiceRequest> for AuthMiddleware
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: MessageBody + 'static,
{
    type Response = ServiceResponse<EitherBody<B>>;
    type Error = Error;
    type InitError = ();
    type Transform = AuthMiddlewareService<S>;
    type Future = Ready<Result<Self::Transform, Self::InitError>>;

    fn new_transform(&self, service: S) -> Self::Future {
        ready(Ok(AuthMiddlewareService {
            service: Rc::new(service),
        }))
    }
}

pub struct AuthMiddlewareService<S> {
    service: Rc<S>,
}

impl<S, B> Service<ServiceRequest> for AuthMiddlewareService<S>
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: MessageBody + 'static,
{
    type Response = ServiceResponse<EitherBody<B>>;
    type Error = Error;
    type Future = LocalBoxFuture<'static, Result<Self::Response, Self::Error>>;

    forward_ready!(service);

    fn call(&self, req: ServiceRequest) -> Self::Future {
        let service = self.service.clone();

        Box::pin(async move {
            let has_token = req.headers().contains_key("x-auth-token");

            if !has_token {
                let response = HttpResponse::Unauthorized().body("Missing auth token");
                return Ok(req.into_response(response).map_into_right_body());
            }

            let response = service.call(req).await?;
            Ok(response.map_into_left_body())
        })
    }
}

Step-by-Step Theory of the Code

Part 1: Middleware marker struct

pub struct AuthMiddleware;

This is the middleware type you attach with:

.wrap(AuthMiddleware)

This struct does not contain logic itself.
It simply represents the middleware.

Part 2: Transform implementation

impl<S, B> Transform<S, ServiceRequest> for AuthMiddleware

This means:

AuthMiddleware can transform an inner service into a middleware-wrapped service.

Here:


S = inner service

B = body type

Part 3: new_transform()

fn new_transform(&self, service: S) -> Self::Future {
    ready(Ok(AuthMiddlewareService {
        service: Rc::new(service),
    }))
}

This is the most important Transform function.

What it does

receives the inner service

wraps it inside AuthMiddlewareService

returns it

So this is the creation layer.

This happens when Actix builds the middleware pipeline.

Part 4: middleware service struct

pub struct AuthMiddlewareService<S> {
    service: Rc<S>,
}

This struct stores the inner service.

After middleware check passes, request will be forwarded to this inner service.

Part 5: Service implementation

impl<S, B> Service<ServiceRequest> for AuthMiddlewareService<S>

This means:

AuthMiddlewareService behaves like a service that can process requests.

This is the runtime layer.

Part 6: call() method

fn call(&self, req: ServiceRequest) -> Self::Future

This method runs on every request.

This is where the actual middleware logic is written.

Part 7: request checking logic

let has_token = req.headers().contains_key("x-auth-token");

Middleware checks whether request has authentication token.

Part 8: block unauthorized request

if !has_token {
    let response = HttpResponse::Unauthorized().body("Missing auth token");
    return Ok(req.into_response(response).map_into_right_body());
}

If token missing:

middleware stops request

returns 401 Unauthorized

This is middleware-generated response.

So it uses:

map_into_right_body()
Part 9: allow request to continue
let response = service.call(req).await?;
Ok(response.map_into_left_body())

If token exists:

middleware forwards request to inner service

handler runs normally

This is handler-generated response.

So it uses:

map_into_left_body()

Simple Understanding of Left and Right Body

In middleware there can be two response sources:

Left body

Normal handler response

Right body

Middleware custom response

So remember:

map_into_left_body() = request allowed

map_into_right_body() = request blocked by middleware

How to Use This Middleware in main.rs

use actix_web::{web, App, HttpResponse, HttpServer, Responder};

mod auth_middleware;
use auth_middleware::AuthMiddleware;

async fn dashboard() -> impl Responder {
    HttpResponse::Ok().body("Welcome to dashboard")
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(
                web::scope("/api")
                    .wrap(AuthMiddleware)
                    .route("/dashboard", web::get().to(dashboard))
            )
    })
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

What Happens at Runtime

App startup

When application starts:

.wrap(AuthMiddleware)

Actix triggers Transform.

So:

Transform creates AuthMiddlewareService

middleware pipeline is prepared

Request 1: No token

User sends request without header:

GET /api/dashboard

Middleware Service runs:

checks header

header missing

returns 401

Output
Missing auth token
Request 2: With token

User sends request with header:

x-auth-token: abc123

Middleware Service runs:

checks header

token exists

forwards request to handler

Handler returns:

Welcome to dashboard

Output Summary

Without token
Status: 401 Unauthorized
Body: Missing auth token
With token
Status: 200 OK
Body: Welcome to dashboard

Why Beginners Get Confused

Many beginners think middleware is only one thing.

They expect:

one struct

one trait

one request handler

But Actix separates middleware into two levels:

Level 1: Creation

Handled by Transform

Level 2: Execution

Handled by Service

This design gives Actix great flexibility.

Interview-Style Answer

If someone asks in interview:

What is the difference between Transform and Service in Actix middleware?

You can answer like this:

In Actix custom middleware, Transform acts as a factory that creates the middleware wrapper around the inner service. It runs when the application pipeline is built. Service contains the actual middleware logic and runs on every incoming request. Transform is the setup layer, while Service is the execution layer.

Objective and MCQ

What is the main purpose of middleware in Actix-web?

A. Handle database queries
B. Intercept requests before they reach handlers
C. Compile Rust code faster
D. Replace HTTP responses

✅ Answer: B
Middleware can inspect or reject requests before they reach handlers.

Middleware in Actix-web is typically implemented using which two traits?

A. Future and Async
B. Transform and Service
C. Handler and Request
D. Router and Scope

✅ Answer: B
Middleware is created using Transform (factory) and Service (execution) traits.

Which Actix type represents an incoming HTTP request inside middleware?

A. HttpRequest
B. ServiceRequest
C. RequestContext
D. RequestBody

✅ Answer: B
ServiceRequest contains the request data processed by middleware.

Which type represents the response returned from middleware or handlers?

A. HttpResponse
B. ServiceResponse
C. ResponseBody
D. HandlerResponse

✅ Answer: B
ServiceResponse wraps both request and response objects.

What happens if middleware decides to block a request?

A. Request continues to handler
B. Middleware returns its own HTTP response
C. Server restarts
D. Request is ignored

✅ Answer: B
Middleware can stop processing and return an early response.

Which HTTP response is commonly returned when authentication fails?

A. 200 OK
B. 401 Unauthorized
C. 201 Created
D. 302 Redirect

✅ Answer: B

Which method in middleware processes each incoming request?

A. execute()
B. handle()
C. call()
D. run()

✅ Answer: C
The call() function is where request processing occurs.

What does forward_ready! macro do in middleware?

A. Sends response to client
B. Forwards readiness check to inner service
C. Creates a request object
D. Serializes JSON

✅ Answer: B

Why does middleware often use generics like ?

A. To support different services and response body types
B. To reduce code size
C. To store database values
D. To handle logging

✅ Answer: A
Generics allow middleware to work with any service and body type.

What does S usually represent in middleware generic parameters?

A. Session object
B. Inner service being wrapped
C. Server configuration
D. Security token

✅ Answer: B

Which trait must response body type implement in Actix middleware?

A. Clone
B. Serialize
C. MessageBody
D. Future

✅ Answer: C

What does the middleware authentication function typically check?

A. Database schema
B. Request headers or session tokens
C. Compiler version
D. JSON parsing

✅ Answer: B

What architectural pattern describes middleware execution order?

A. MVC pattern
B. Onion / pipeline pattern
C. Observer pattern
D. Singleton pattern

✅ Answer: B
Middleware layers wrap around handlers like an onion structure.

In route protection middleware, what usually happens when the user is authenticated?

A. Request stops
B. Middleware calls the inner service
C. Server logs out user
D. Database connection closes

✅ Answer: B

Which Actix function allows attaching middleware to an application?

A. attach()
B. wrap()
C. register()
D. bind()

✅ Answer: B
App::wrap() attaches middleware.

Which type is commonly used to represent asynchronous middleware results?

A. Result
B. LocalBoxFuture
C. AsyncResponse
D. FutureResult

✅ Answer: B

What is the role of Transform trait in middleware?

A. Handle request execution
B. Create middleware service instances
C. Manage database connections
D. Serialize responses

✅ Answer: B

Which scenario is a common use case for route protection middleware?

A. Image processing
B. Authentication and authorization
C. File compression
D. Code compilation

✅ Answer: B

Which middleware logic is typically executed before the handler?

A. Response serialization
B. Authentication check
C. Database backup
D. File upload

✅ Answer: B

What is the main advantage of middleware-based route protection?

A. Reduces database size
B. Centralizes authentication logic
C. Removes need for handlers
D. Increases CPU usage

✅ Answer: B
Middleware centralizes authentication and security checks for multiple routes.

Understanding Generic Structs in Rust

rakesh kumar — Fri, 06 Mar 2026 00:42:36 +0000

For example, you may want a Box-like struct that can store:
What Are Generics in Simple Words?
Why Generic Structs Are Useful
Basic Problem Without Generics
The Solution: Generic Struct
Real-Life Use Case of Generic Structs
Why middleware needs generics
Objective and MCQ

an integer (i32)

a string (String)

a float (f64)

or even a custom struct

If you don’t use generics, you end up writing separate structs for each type, which is repetitive and hard to maintain.

That’s exactly why generics exist in Rust.

What Are Generics in Simple Words?

A generic type is like a placeholder.

Instead of saying:

“This struct only stores i32”

You say:

“This struct can store any type”

And Rust will decide the type when you create the struct.

Why Generic Structs Are Useful

Generic structs help you:
Avoid duplicate code
Make reusable data structures
Write clean and scalable programs
Keep your code type-safe (Rust still checks types strictly)

Basic Problem Without Generics

Let’s say you want a struct to store a value.

Example 1: Struct for only i32

struct IntBox {
    value: i32,
}

fn main() {
    let a = IntBox { value: 10 };
    println!("IntBox value = {}", a.value);
}

✅ Output:

IntBox value = 10

Now if you want to store a string, you must create a new struct:

Example 2: Struct for only String

struct StringBox {
    value: String,
}

fn main() {
    let b = StringBox { value: "Hello".to_string() };
    println!("StringBox value = {}", b.value);
}

✅ Output:

StringBox value = Hello

See the problem?

You are writing two structs doing the same job, just with different types.

The Solution: Generic Struct

Now we create one struct that works for all types:

Generic Struct Syntax

struct BoxValue<T> {
    value: T,
}

Here:

T means any type

BoxValue<T> becomes:

BoxValue<i32>

BoxValue<String>

BoxValue<f64>

etc.

✅ Coding Example: Generic Struct with Different Types

struct BoxValue<T> {
    value: T,
}

fn main() {
    let a = BoxValue { value: 10 };
    let b = BoxValue { value: "Hello" };
    let c = BoxValue { value: 99.5 };

    println!("a = {}", a.value);
    println!("b = {}", b.value);
    println!("c = {}", c.value);
}

✅ Output:

a = 10
b = Hello
c = 99.5

What Happened Here?

Rust automatically decides:

a is BoxValue<i32>

b is BoxValue<&str>

c is BoxValue<f64>

One struct, many types.

Generic Struct with Methods (impl)

Generic structs become more powerful when we add methods.

Example: Add a method get()

struct BoxValue<T> {
    value: T,
}

impl<T> BoxValue<T> {
    fn get(&self) -> &T {
        &self.value
    }
}

fn main() {
    let a = BoxValue { value: 10 };
    let b = BoxValue { value: "Rust" };

    println!("a = {}", a.get());
    println!("b = {}", b.get());
}

✅ Output:

a = 10
b = Rust

Meaning of impl<T>

impl means:

“Implement these methods for BoxValue of any type T”

So get() works for i32, String, &str, and everything else.

Generic Struct with Two Types

Sometimes you want to store two different types in the same struct.

Example: store a pair.

Coding Example

struct Pair<T, U> {
    first: T,
    second: U,
}

fn main() {
    let p1 = Pair { first: 10, second: "Hello" };
    let p2 = Pair { first: "Name", second: 99.9 };

    println!("p1 = {} {}", p1.first, p1.second);
    println!("p2 = {} {}", p2.first, p2.second);
}

✅ Output:

p1 = 10 Hello
p2 = Name 99.9

Here:

p1 is Pair<i32, &str>

p2 is Pair<&str, f64>

Real-Life Use Case of Generic Structs

Generic structs are used everywhere in Rust, such as:

Vec → vector of any type

Option → optional value of any type

Result → success type and error type

Example:

let nums: Vec<i32> = vec![1, 2, 3];
let name: Option<&str> = Some("Ashwani");

Summary

✅ A generic struct uses placeholders like T, U to support many types.

✅ Instead of writing:

IntBox

StringBox

FloatBox

You write one struct:

BoxValue<T>

✅ Generic structs keep code:

reusable

clean

scalable

type-safe

Why middleware needs generics

Because different handlers are different types

In Actix, each handler/service is not the same Rust type.

Example:

async fn dashboard() -> HttpResponse {
    HttpResponse::Ok().body("Dashboard")
}

async fn profile() -> HttpResponse {
    HttpResponse::Ok().body("Profile")
}

Even if both return HttpResponse, internally the service pipeline around them may be different.

If middleware was not generic, you would have to write middleware for one exact service type only.

Generics solve that.

So:

AuthMiddlewareService<S>

means:

wrap any service type S

Because response body types can be different

Different routes may return different body types:

plain text

JSON

HTML

file response

custom responder body

So middleware cannot assume only one body type.

That is why you use:

B: MessageBody

This means:

whatever body type the inner service returns, it must be a valid Actix body

So B keeps the middleware flexible.

Objective and MCQ

1) Why does middleware in Actix commonly use generics like AuthMiddlewareService?

A. To avoid using async/await
B. Because different handlers/services are different Rust types
C. Because Rust does not support traits
D. To make code slower but safer
✅ Answer: B

2) In struct BoxValue { value: T }, what does T represent?

A. A fixed integer type
B. A placeholder for “any type” chosen at compile time
C. A runtime dynamic type
D. A pointer type
✅ Answer: B

3) Without generics, storing i32 and String typically leads to:

A. One struct that auto-converts types
B. Duplicate structs for each type (repetition)
C. Faster compilation only
D. Trait objects everywhere
✅ Answer: B

4) Which is the correct generic struct syntax?

A. struct BoxValue(value: T)
B. struct BoxValue { value: T }
C. struct BoxValue[T] { value: T }
D. struct BoxValue { value: }
✅ Answer: B

5) What does impl BoxValue mean?

A. Implement methods only for BoxValue
B. Implement methods for BoxValue of any type T
C. Implement methods at runtime depending on input
D. Implement methods only for String
✅ Answer: B

6) In a generic method fn get(&self) -> &T, what is returned?

A. A copy of T always
B. A reference to the stored value
C. A mutable reference always
D. A string representation
✅ Answer: B

7) Which generic struct supports storing two different types?

A. struct Pair { first: T, second: U }
B. struct Pair { first: T, second: T }
C. struct Pair { first: T, second: U }
D. struct Pair { ... }
✅ Answer: A

8) If p1 = Pair { first: 10, second: "Hello" }, then p1 is:

A. Pair
B. Pair
C. Pair
D. Pair<&str, &str>
✅ Answer: B

9) In Actix middleware, why is the response body often generic as B?

A. Because every route returns the same body type
B. Because different routes can return different body types (text/JSON/HTML/etc.)
C. Because HttpResponse can’t carry bodies
D. Because generics are required in every Rust file
✅ Answer: B

10) Which constraint ensures the body type is valid for Actix?

A. B: Clone
B. B: Default
C. B: MessageBody
D. B: Send + Sync
✅ Answer: C

11) In AuthMiddlewareService, what does S usually represent?

A. A String
B. The wrapped inner service/handler pipeline type
C. A Session
D. A Server config object
✅ Answer: B

12)Which statement best describes why generics keep middleware reusable?

A. It makes middleware work only for one route
B. It lets middleware wrap “any service type S” instead of one fixed type
C. It removes the need for HTTP responses
D. It converts Rust into a dynamic language
✅ Answer: B

13) Which of these is a real-life generic type example mentioned in the topic?

A. Vec
B. Tree (as a built-in)
C. Json (as Rust standard library)
D. Router (as standard)
✅ Answer: A

14) Option<&str> is an example of:

A. A non-generic type
B. A generic type instantiated with &str
C. A macro expansion only
D. A runtime reflection type
✅ Answer: B

15) Which is TRUE about generics in Rust?

A. Rust decides T only at runtime
B. Generics reduce type safety
C. Generics help reuse code while staying type-safe
D. Generics require garbage collection
✅ Answer: C

16) If middleware returns unauthorized early, but otherwise passes through the inner service, why might Actix use an “either body” approach?

A. Because both branches must have the same exact body type
B. Because unauthorized and normal responses may have different body types, so they’re unified into one response body type
C. Because Rust cannot return a response
D. Because cookies require it
✅ Answer: B (matches the “different body types” idea behind B: MessageBody)

17) In generic structs, what is the main benefit compared to writing IntBox, StringBox, FloatBox separately?

A. More duplication
B. One reusable struct for many types
C. Only works for numbers
D. Only works for strings
✅ Answer: B

18) Which of the following is a correct instantiation idea for BoxValue?

A. BoxValue stores an i32
B. BoxValue stores a String
C. BoxValue stores an i32
D. BoxValue stores a bool only
✅ Answer: A

19) In Actix, even if two handlers both “return HttpResponse”, why can their internal service pipeline types differ?

A. Because Rust randomly changes types
B. Because different routes/middleware stacks can create different composed service types
C. Because HttpResponse is generic
D. Because handlers cannot be async
✅ Answer: B

20) Best summary: “Why middleware needs generics” includes which TWO main reasons?

A. (1) Generics make code longer, (2) generics avoid traits
B. (1) Different handlers/services are different types, (2) response body types can differ
C. (1) Generics remove async, (2) generics remove JSON
D. (1) Generics are only for performance, (2) generics are only for macros
✅ Answer: B

Understanding Different Types of Service Responses in Rust

rakesh kumar — Fri, 06 Mar 2026 00:21:22 +0000

Introduction
What Is a Service Response in Rust?
Types of Service Responses in Rust
Result Response
Option Response
Structured API Response
HTTP Service Response
Middleware Service Response
Generic Service Response
EitherBody Response
Objective and MCQ

Introduction

When building backend services in Rust—especially with web frameworks like Actix-Web or similar service architectures—handling responses properly is crucial. A service response represents the output returned after a request is processed by a handler, middleware, or service layer.

Rust encourages explicit and type-safe response handling. Instead of loosely structured outputs, Rust relies on clear types and structures to represent successful results, errors, optional values, or HTTP responses. This approach improves reliability, readability, and maintainability in server applications.

In this blog, we will explore the different types of service responses in Rust, understand the theory behind them, and examine their syntax with simple coding examples.

What Is a Service Response in Rust?

A service response is the result returned by a function or service after processing input. It could represent:

Successful execution

Failure or error

Optional data

HTTP response for APIs

Structured response objects

In Rust-based services, responses are usually expressed through types, ensuring safe and predictable program behavior.

Types of Service Responses in Rust

Common response types used in Rust services include:

Result Response

Option Response

Structured API Response

HTTP Service Response

Middleware Service Response

Generic Service Response

Let's explore each type.

Result Response

The Result type is used when a service operation may succeed or fail.

Theory

Rust avoids exceptions. Instead, functions return Result to represent two possibilities:


Ok(T) → operation successful

Err(E) → operation failed

Syntax

Result<T, E>

Where:

T = success type

E = error type

Example

fn fetch_user(id: i32) -> Result<String, String> {

    if id == 1 {
        Ok("User Found".to_string())
    } else {
        Err("User Not Found".to_string())
    }

}

fn main() {

    let response = fetch_user(1);

    match response {
        Ok(data) => println!("Success: {}", data),
        Err(e) => println!("Error: {}", e),
    }

}

Output

Success: User Found

Option Response

The Option type represents a value that may or may not exist.

Theory

Instead of returning null values, Rust uses:

Some(value)

None

Syntax

Option<T>

Example

fn find_number(num: i32) -> Option<i32> {

    if num == 10 {
        Some(num)
    } else {
        None
    }

}

fn main() {

    match find_number(10) {
        Some(v) => println!("Found {}", v),
        None => println!("Value not found"),
    }

}

Output

Found 10

Structured Service Response

Often APIs return structured responses containing metadata.

Theory

Instead of returning raw values, services return structured response objects containing:

success status

message

data

Syntax

struct ApiResponse<T>

Example

struct ApiResponse<T> {
    success: bool,
    message: String,
    data: T,
}

fn main() {

    let response = ApiResponse {
        success: true,
        message: "User created".to_string(),
        data: 101,
    };

    println!("Status: {}", response.success);
    println!("Message: {}", response.message);
}

Output

Status: true
Message: User created

HTTP Service Response

When building web services, responses are returned as HTTP responses.

Theory

Frameworks like Actix-Web allow creating responses using HTTP status codes and body content.

Syntax

HttpResponse::Status().body(data)

Example

use actix_web::HttpResponse;

fn success() -> HttpResponse {

    HttpResponse::Ok().body("Request Successful")

}

Output

HTTP 200 OK
Request Successful

Middleware Service Response

Middleware sits between the request and handler. It can modify or generate responses.

Theory

In middleware, responses are often wrapped using:

ServiceResponse

This type contains:

request context

response body

status information

Conceptual Flow

Request
   ↓
Middleware
   ↓
Handler
   ↓
ServiceResponse

Example Concept

let response = HttpResponse::Unauthorized().body("Login required");
req.into_response(response);

This creates a ServiceResponse from an HTTP response.

Generic Service Response

Rust also supports generic responses that can handle different types of data.

Theory

Generics allow services to return flexible data types.

Syntax

struct Response<T>

Example

struct Response<T> {
    data: T,
}

fn main() {

    let r1 = Response { data: 10 };
    let r2 = Response { data: "Rust Service" };

    println!("r1: {}", r1.data);
    println!("r2: {}", r2.data);

}

Output

r1: 10
r2: Rust Service

EitherBody Response

EitherBody comes under the Middleware / Service Response Body category in Rust web frameworks like Actix-Web.

Category of EitherBody

Category:

Middleware Response Body Type

or more precisely:

Service Response Body Wrapper

Why EitherBody Exists

In middleware, two different responses can happen:

Middleware-generated response

Example: authentication failed

Handler-generated response

Example: dashboard data returned by handler

Rust requires one fixed response type, but middleware may return two different responses.

So Actix provides:

EitherBody<B>

to combine both.

Concept

EitherBody
   ├── Left  → handler response
   └── Right → middleware response

So middleware can safely return either response.

Syntax

ServiceResponse<EitherBody<B>>

Where:

B = handler response body type

Example
Middleware Example

use actix_web::{
    body::EitherBody,
    dev::{ServiceRequest, ServiceResponse},
    HttpResponse,
};

fn example(req: ServiceRequest) -> ServiceResponse<EitherBody> {

    let authenticated = false;

    if !authenticated {

        let res = HttpResponse::Unauthorized().body("Login required");

        return req.into_response(res).map_into_right_body();
    }

    let res = HttpResponse::Ok().body("Welcome user");

    req.into_response(res).map_into_left_body()
}

Output Behavior
Case 1 — Not logged in
Status: 401 Unauthorized
Body: Login required

This response uses:

map_into_right_body()

Meaning:

EitherBody → Right
Case 2 — Logged in
Status: 200 OK
Body: Welcome user

This response uses:

map_into_left_body()

Meaning:

EitherBody → Left

Where EitherBody Is Mostly Used

EitherBody is commonly used in:

Actix middleware

Authentication middleware

Rate limiting middleware

Request validation middleware

Error handling middleware

Because middleware may either:

Allow request → call handler
OR
Block request → return response

. What is ServiceResponse in Actix-web?

A. Database response
B. HTTP request container
C. Wrapper around request and response
D. Logging structure

✅ Answer: C
ServiceResponse wraps both the request and the generated HTTP response.

Which function returns the HTTP status code from ServiceResponse?

A. status()
B. code()
C. response_status()
D. get_status()

✅ Answer: A
status() returns the HTTP status code of the response.

What does ServiceResponse represent?

A. Response with generic body type B
B. Fixed JSON response
C. Static HTML response
D. Database response

✅ Answer: A

What trait must the body type implement in Actix responses?

A. Clone
B. MessageBody
C. Future
D. Serialize

✅ Answer: B

What does EitherBody represent in Actix?

A. Database results
B. Two possible body types in a response
C. JSON parser
D. Error handler

✅ Answer: B
EitherBody allows responses to contain one of two body types.

Why is EitherBody commonly used in middleware?

A. To store database records
B. To return either inner service response or middleware response
C. To compress responses
D. To run async tasks

✅ Answer: B
Middleware often returns either the inner service response or its own error response.

Which method converts response body type to BoxBody?

A. map_into_boxed_body()
B. box_body()
C. convert_body()
D. wrap_body()

✅ Answer: A
map_into_boxed_body() converts a body into BoxBody.

Which method converts a response into EitherBody (Left variant)?

A. map_into_left_body()
B. map_into_boxed_body()
C. map_left()
D. into_left()

✅ Answer: A

Which method converts a response into EitherBody (Right variant)?

A. map_into_left_body()
B. map_into_right_body()
C. map_into_boxed_body()
D. map_into_service()

✅ Answer: B

What does map_body() do in ServiceResponse?

A. Deletes response body
B. Maps body to another type
C. Converts body to JSON
D. Logs body

✅ Answer: B
It transforms the response body to another type using a closure.

What is the default right variant of EitherBody?

A. String
B. BoxBody
C. Vec
D. Json

✅ Answer: B
The right variant defaults to BoxBody.

Which method returns reference to the original request?

A. get_request()
B. request()
C. original_request()
D. req()

✅ Answer: B
request() returns reference to the original request.

Which function extracts response and request parts?

A. split()
B. extract()
C. into_parts()
D. unwrap()

✅ Answer: C
into_parts() separates request and response components.

Which component typically generates the final response?

A. Database
B. Middleware
C. Handler
D. Logger

✅ Answer: C
Handlers generate the main HTTP responses.

In middleware, what happens if authentication fails?

A. Request continues
B. Middleware returns its own response
C. Database handles it
D. Program stops

✅ Answer: B

Which HTTP response might middleware generate for unauthorized access?

A. 200 OK
B. 201 Created
C. 401 Unauthorized
D. 204 No Content

✅ Answer: C

What is the purpose of generics in ServiceResponse?

A. To support different body types
B. To store database records
C. To enable logging
D. To enable caching

✅ Answer: A

Which response body types can Actix support?

A. JSON
B. Text
C. HTML
D. All of the above

✅ Answer: D

19.** What architecture pattern does Actix middleware follow?**

A. Pipeline pattern
B. Onion/chain pattern
C. MVC pattern
D. Repository pattern

✅ Answer: B
Requests pass through middleware layers like an onion structure.

Why do middleware responses often use generics?

A. To reduce code size
B. Because body types from inner services are unknown
C. To speed up compilation
D. To simplify syntax

✅ Answer: B
Middleware must support unknown body types returned by handlers

Understanding Different Types of Responses in Rust: Theory, Syntax, and Practical Examples

rakesh kumar — Fri, 06 Mar 2026 00:03:51 +0000

Introduction
custom structured responses
Common Response Types in Rust
Result
Option
HttpResponse (Web APIs)
impl Responder
ServiceResponse
Custom struct responses
JSON responses
Objective and MCQ

Introduction

When building backend applications or APIs in Rust, returning the correct response type is very important. A response is the data that the server sends back to the client after processing a request.

Rust provides several ways to return responses depending on the situation. For example, a function may return:

a success response

an error response

optional data

JSON data

custom structured responses

Understanding these response types helps developers build clean, safe, and maintainable Rust applications.

What is a Response in Rust?

A response represents the result of a computation or request. It tells the caller whether the operation:

succeeded

failed

returned data

returned nothing

Rust commonly uses special enums and types to represent responses safely.

Common Response Types in Rust

The most commonly used response types are:

Result<T, E>

Option<T>

HttpResponse (Web APIs)

impl Responder

ServiceResponse

Custom struct responses

JSON responses

Let's understand each with syntax and examples.

Result Response

The Result type is used when an operation may succeed or fail.

Syntax

Result<T, E>

Where:

T = success value
E = error value

Example

fn divide(a: i32, b: i32) -> Result<i32, String> {

    if b == 0 {
        return Err("Cannot divide by zero".to_string());
    }

    Ok(a / b)
}

fn main() {

    let result = divide(10, 2);

    match result {
        Ok(value) => println!("Result: {}", value),
        Err(e) => println!("Error: {}", e),
    }

}

Output

Result: 5

Option Response

Option is used when a value may or may not exist.

Syntax

Option<T>

Possible values:


Some(value)
None

Example

fn find_number(numbers: Vec<i32>, target: i32) -> Option<i32> {

    for n in numbers {
        if n == target {
            return Some(n);
        }
    }

    None
}

fn main() {

    let result = find_number(vec![1,2,3,4], 3);

    match result {
        Some(n) => println!("Found: {}", n),
        None => println!("Not found"),
    }

}

Output

Found: 3

HttpResponse (Web APIs)

When building APIs using Actix-Web, responses are created using HttpResponse.

Syntax

HttpResponse::StatusCode().body(data)

Example

use actix_web::{HttpResponse};

fn success_response() -> HttpResponse {
    HttpResponse::Ok().body("Request successful")
}

Output

Status: 200 OK
Body: Request successful

JSON Response

Most APIs return JSON responses.

Syntax

HttpResponse::Ok().json(data)

Example

use actix_web::HttpResponse;
use serde::Serialize;

#[derive(Serialize)]
struct User {
    name: String,
    age: u8
}

fn user_response() -> HttpResponse {

    let user = User {
        name: "Ashwani".to_string(),
        age: 30
    };

    HttpResponse::Ok().json(user)
}

Example JSON Output

{
 "name": "Ashwani",
 "age": 30
}

impl Responder

Rust frameworks allow returning any type that implements Responder.

Syntax

async fn handler() -> impl Responder

Example

use actix_web::{Responder, HttpResponse};

async fn hello() -> impl Responder {
    HttpResponse::Ok().body("Hello Rust")
}

Output

Hello Rust

Custom Struct Response

Sometimes we create structured responses for APIs.

Syntax

struct ApiResponse<T>

Example

use serde::Serialize;

#[derive(Serialize)]
struct ApiResponse<T> {
    success: bool,
    data: T
}

fn main() {

    let response = ApiResponse {
        success: true,
        data: "User created"
    };

    println!("Success: {}", response.success);

}

Output

Success: true

ServiceResponse (Middleware Response)

When working with Actix middleware, responses are wrapped inside ServiceResponse.

Syntax

ServiceResponse<B>

Example concept:

ServiceRequest → Middleware → ServiceResponse

Middleware may modify responses before sending them back to the client.

Summary

Objective and MCQ

What is the most commonly used HTTP response type in Actix-web?

A. ResponseData
B. HttpResponse
C. ServerResponse
D. ApiResponse

✅ Answer: B
HttpResponse is the primary type used to construct HTTP responses in Actix-web.

Which trait allows Actix handlers to return multiple response types?

A. Display
B. Responder
C. Clone
D. Debug

✅ Answer: B
Handler functions can return any type implementing the Responder trait.

Which method finalizes a response builder with body content?

A. .finish()
B. .body()
C. .complete()
D. .close()

✅ Answer: B
.body() finalizes the HttpResponseBuilder with response content.

Which method is used to send JSON data in an Actix response?

A. .json()
B. .data()
C. .serialize()
D. .send_json()

✅ Answer: A
.json() converts a structure to JSON response.

What does HttpResponse::Ok() represent?

A. HTTP 200 response
B. HTTP 404 response
C. HTTP 500 response
D. HTTP 201 response

✅ Answer: A
Ok() creates a response builder with status code 200.

Which status code indicates resource creation?

A. 200
B. 201
C. 404
D. 500

✅ Answer: B
HttpResponse::Created() represents status code 201.

Which HTTP response indicates authentication failure?

A. 200
B. 403
C. 401
D. 302

✅ Answer: C
401 Unauthorized indicates authentication failure.

Which HTTP response indicates resource not found?

A. 401
B. 404
C. 403
D. 500

✅ Answer: B
404 Not Found is returned when a resource is missing.

What type is commonly used for JSON responses in Actix?

A. Json
B. Map
C. Data
D. String

✅ Answer: A
Json serializes Rust structures into JSON responses.

Which response type is used for plain text responses?

A. HttpResponse::Ok().body("text")
B. TextResponse
C. StringResponse
D. PlainResponse

✅ Answer: A

What does ServiceResponse represent?

A. Only HTTP body
B. HTTP request + response wrapper
C. Only HTTP headers
D. Only status code

✅ Answer: B
ServiceResponse wraps both the request and response objects.

Why are generics used in ServiceResponse?

A. To support multiple body types
B. To increase performance only
C. To store database values
D. To reduce memory usage

✅ Answer: A
Generic B allows different body types in responses.

Which body type trait must response bodies implement?

A. Future
B. MessageBody
C. Serialize
D. BodyTrait

✅ Answer: B
Actix requires response body types to implement MessageBody.

Which type allows returning two possible response body types?

A. DualBody
B. EitherBody
C. OptionalBody
D. VariantBody

✅ Answer: B
EitherBody allows two alternative body types.

Why is EitherBody useful in middleware?

A. To reduce memory usage
B. To return either middleware response or inner service response
C. To store request data
D. To parse JSON

✅ Answer: B
Middleware may return either its own response or the inner service response.

Which method converts body to a boxed type?

A. box_body()
B. map_into_boxed_body()
C. convert_body()
D. wrap_body()

✅ Answer: B
This converts the response body into BoxBody.

Which method changes the response body using a closure?

A. map_response()
B. map_body()
C. convert_body()
D. update_body()

✅ Answer: B
map_body() transforms the response body type.

What is the purpose of HTTP response headers?

A. Store database values
B. Provide metadata about the response
C. Control server execution
D. Encrypt responses

✅ Answer: B

Which HTTP response indicates a server error?

A. 404
B. 403
C. 500
D. 201

✅ Answer: C
500 Internal Server Error indicates server failure.

Why are different response types used in Rust web APIs?

A. To support various content formats and HTTP statuses
B. To reduce Rust compilation time
C. To remove middleware
D. To simplify database queries

✅ Answer: A
Different response types allow APIs to return JSON, text, HTML, or error responses depending on the situation.

why Rust futures must be pinned

rakesh kumar — Thu, 05 Mar 2026 23:39:32 +0000

.What is Box in Rust?
Why Heap Memory is Useful
What is Pin?
What is Box::pin?
Why Box::pin is Used in Async Code
Why Box::pin is Needed in Middleware
Objective and mcq

What is Box

What is Pin

Why Box::pin is needed

What is Box in Rust?

A Box stores a value on the heap memory instead of the stack.

Example

fn main() {

    let a = 10;              // stored on stack
    let b = Box::new(20);    // stored on heap

    println!("a = {}", a);
    println!("b = {}", b);

}

Output

a = 10
b = 20

Here:

a → stack memory
b → heap memory

Rust moves large or dynamic data to the heap using Box.

Why Heap Memory is Useful

Stack memory must know exact size at compile time.

But sometimes Rust needs dynamic memory.

Example:

async futures

recursive types

large data structures

So we use:

Box<T>

What is Pin?

Pin means a value cannot move in memory after being placed somewhere.

Why?

Some async operations depend on memory not changing location.

Think of it like:

Pin = Fix the object in memory

Example analogy:

Stack variable → movable
Pinned variable → fixed position

What is Box::pin?

Box::pin does two things together:

Stores the value in heap memory

Pins the value so it cannot move

So:

Box::pin(value)

means:

Put value on heap
and fix its memory location

Basic Example of Box::pin Code use std::pin::Pin;

fn main() {

    let value = Box::pin(100);

    println!("Pinned value = {}", value);

}

`Output`
Pinned value = 100

Here:

100 → stored on heap
and pinned

Why Box::pin is Used in Async Code

Async functions create Future objects.

Example async function:

async fn say_hello() {
    println!("Hello from async function");
}

This function actually returns a Future.

But Rust cannot easily store unknown-sized futures.

So we wrap them using:

Box::pin(future)

Simple Async Example Code

use std::future::Future;
use std::pin::Pin;

async fn greet() {
    println!("Hello Rust");
}

fn main() {

    let future: Pin<Box<dyn Future<Output = ()>>> = Box::pin(greet());

}

Explanation

Box → store future on heap
Pin → future cannot move

Example Similar to Actix Middleware

Actix middleware returns this type:

LocalBoxFuture<'static, Result>

This is usually created like:

Box::pin(async move {

    println!("Middleware running");

    Ok(response)

})

Example

use std::future::Future;
use std::pin::Pin;

fn main() {

    let future = Box::pin(async {

        println!("Async task running");

    });

}

Output (when executed)
Async task running

Why Box::pin is Needed in Middleware

In Actix middleware we often see:

fn call(&self, req: ServiceRequest) -> Self::Future {

    Box::pin(async move {

        println!("Middleware executing");

    })
}

Why?

Because:

async block → creates a Future
Future size → unknown at compile time

So Rust requires:

Box::pin(async block)

to place it safely on heap.

Simple Visualization

Without Box::pin

async block
   ↓
Unknown size future
   ↓
Rust cannot store it

With Box::pin

async block
   ↓
Future
   ↓
Box (heap storage)
   ↓
Pinned memory location

Real World Analogy

Think of memory like a parking lot.

Normal variable:

Car parked temporarily
It can move anytime

Pinned variable:

Car fixed in a reserved parking slot
Cannot move

Box::pin does exactly this.

Small Practical Example

use std::pin::Pin;

fn main() {

    let data = Box::pin(String::from("Rust Programming"));

    println!("{}", data);

}

Output
Rust Programming

Here:

String stored in heap
Pinned to fixed location

When working with async programming in Rust, you often see concepts like:

Pin

Box::pin

Future

Many developers ask:

Why do Rust futures need to be pinned?

The reason is connected to how async functions work internally.

What an Async Function Actually Returns

When you write this:

async fn hello() {
    println!("Hello Rust");
}

Rust does not immediately run the function.

Instead, Rust converts it into a Future.

Conceptually it becomes something like:

fn hello() -> impl Future<Output = ()>

So an async function returns a Future object.

Futures Work Like State Machines

Rust transforms async code into a state machine.

Example async code:

async fn example() {
    step1().await;
    step2().await;
}

Internally Rust converts this into something like:

State 0 → Start
State 1 → After step1
State 2 → After step2

Each await point stores data inside the future struct.

So the future keeps internal references to its own memory.

The Problem: Moving Futures in Memory

Normally in Rust, values can move in memory.

Example:

fn main() {

    let a = String::from("Rust");

    let b = a; // moved

}

When values move:

Old memory → invalid
New memory → new location

This is normally safe.

But for futures it creates a problem.

The Self-Reference Problem

Async futures may contain references to their own internal fields.

Example conceptually:

Future Struct


field1: String
field2: reference to field1

Visual example:

Memory location: 0x1000

field1 → "hello"
field2 → reference to 0x1000

Now imagine the future moves to another location:

New memory: 0x2000

But the reference still points to:

0x1000

Which is now invalid.

This causes memory safety issues.

Rust prevents this by pinning the future.

What Pinning Does

Pinning means:

Once placed in memory → cannot move

So if a future is pinned:

Future memory address stays fixed

This guarantees that internal references remain valid.

Example Without Pin (Conceptual Problem)

Consider this conceptual future:

struct MyFuture {
    data: String,
    reference: *const String,
}

If the struct moves:


data moves to new location
reference still points to old location

This breaks memory safety.

Rust avoids this by requiring:

Pinned Futures

Simple Example of Pin

use std::pin::Pin;

fn main() {

    let value = Box::pin(10);

    println!("Pinned value: {}", value);

}

Output

Pinned value: 10

Here:

10 is stored on heap
and pinned so it cannot move

Async Example with Pin

use std::future::Future;
use std::pin::Pin;

async fn say_hello() {
    println!("Hello Rust Async");
}

fn main() {

    let future: Pin<Box<dyn Future<Output = ()>>> =
        Box::pin(say_hello());

}

Here:

Future stored on heap
Future pinned
Memory location fixed

Why Middleware Uses Box::pin

A Box stores a value on the heap memory instead of the stack.

Example

fn main() {

    let a = 10;              // stored on stack
    let b = Box::new(20);    // stored on heap

    println!("a = {}", a);
    println!("b = {}", b);

}

Output

a = 10
b = 20

Here:

a → stack memory
b → heap memory

Rust moves large or dynamic data to the heap using Box.

In Actix middleware you often see:

Box::pin(async move {

    println!("Middleware running");

})

Why?

Because:

async block → creates a Future
Future size → unknown
Future may contain self references

So Rust requires:

Box::pin(async block)

to safely store and pin it.

Why Heap Memory is Useful

Stack memory must know exact size at compile time.

But sometimes Rust needs dynamic memory.

Example:

async futures

recursive types

large data structures

So we use:

Box<T>

Visual Summary

Without pinning:

Future
  │
  ▼
Memory moves
  │
  ▼
Internal references break

`With pinning:`

Future
  │
  ▼
Pinned memory location
  │
  ▼

References remain valid

Real-World Analogy

Imagine a map with a location marker.

Normal variable:

House moves → map still points to old place

Pinned variable:

House fixed → map always correct

Pinning ensures that the address never changes.

When Futures Must Be Pinned

Futures must be pinned when:

they contain self-references

they are polled multiple times

they are stored in heap structures

they are used in async frameworks

Examples:

Actix Web
Tokio
Hyper
Async executors

Key Takeaway

Rust futures must be pinned because:

Async futures may contain references to their own internal memory.
If the future moves, those references break.
Pinning prevents movement and keeps memory safe.

What is the main purpose of pinning a future in Rust?

A. Increase execution speed
B. Prevent the future from moving in memory
C. Allow multiple threads to run
D. Reduce compilation time

✅ Answer: B
Pinning guarantees the value will not move in memory.

Why do many Rust futures require pinning?

A. Futures require heap allocation
B. Futures often contain self-references
C. Futures cannot use references
D. Futures always run in parallel

✅ Answer: B
Many futures are self-referential, so they must stay in a fixed memory location.

What happens if a self-referential future moves in memory?

A. Execution becomes faster
B. References become invalid
C. Memory is automatically fixed
D. Nothing happens

✅ Answer: B
Moving such a structure breaks internal references.

Which Rust type ensures a value cannot move after being pinned?

A. Future
B. Pin
C. Box
D. Ref

✅ Answer: B
Pin

guarantees the pointed value will not move.

W*hich trait indicates that a type can safely move even if pinned?*

A. Copy
B. Send
C. Unpin
D. Clone

✅ Answer: C
Unpin means the value can move safely even when wrapped in Pin.

What does the Future::poll() method require as its first parameter?

A. &Self
B. Pin<&mut Self>
C. Box
D. Self

✅ Answer: B
The future must be pinned before polling.

Why does poll() require Pin<&mut Self>?

A. To allow multiple threads
B. To guarantee the future will not move
C. To increase performance
D. To reduce memory

✅ Answer: B
Pinning ensures safe polling of self-referential futures.

What does async/await compile into internally?

A. Threads
B. State machines
C. Processes
D. Channels

✅ Answer: B
Async functions are compiled into state machines.

Why can async state machines become self-referential?

A. They store references across .await points
B. They allocate memory on heap
C. They use threads
D. They call external libraries

✅ Answer: A
Variables stored across await points may reference each other.

What does pinning guarantee about a future’s memory address?

A. It changes frequently
B. It remains constant
C. It moves automatically
D. It becomes static

✅ Answer: B
Pinning keeps the memory location fixed.

Which function is commonly used to pin a future on the heap?

A. Box::new()
B. Box::pin()
C. Pin::wrap()
D. Future::pin()

✅ Answer: B

What kind of data structure often requires pinning?

A. Numeric values
B. Self-referential structures
C. Static variables
D. Boolean flags

✅ Answer: B
Self-referential data must remain at a fixed location.

Which Rust feature generates futures automatically?

A. match
B. async fn
C. loop
D. impl

✅ Answer: B

Which keyword waits for a future to complete?

A. wait
B. future
C. await
D. async

✅ Answer: C

15.** What problem does pinning primarily prevent?**

A. CPU overload
B. Dangling references
C. Thread starvation
D. Compilation errors

✅ Answer: B
Moving self-referential futures could create dangling pointers.

Which pointer types can be wrapped by Pin?

A. Only Box
B. Only &T
C. Pointer types like &mut T or Box
D. Only Vec

✅ Answer: C
Pin wraps pointer types to prevent movement.

When should a future typically be pinned?

A. Before it is polled
B. After execution completes
C. After compilation
D. Before writing code

✅ Answer: A
Futures must be pinned before polling begins.

Which scenario allows a pinned value to still move safely?

A. If the type implements Unpin
B. If the future is async
C. If the value is boxed
D. If the runtime moves it

✅ Answer: A
Unpin indicates movement is safe even when pinned.

What is the relationship between Pin and async runtimes?

A. Runtimes require pinned futures for safe polling
B. Runtimes ignore pinning
C. Pinning disables async runtime
D. Pinning removes futures

✅ Answer: A
Executors rely on pinned futures for safe execution.

What is the key concept behind pinning in Rust async programming?

A. Memory stability for asynchronous tasks
B. Faster execution
C. Smaller binaries
D. Thread synchronization

✅ Answer: A
Pinning ensures memory stability and safe async execution.

Security Headers Middleware in Actix-Web (Rust)

rakesh kumar — Thu, 05 Mar 2026 14:06:29 +0000

Production-ready theory + step-by-step code flow (main.rs → middleware → handler → db)

Security headers are HTTP response headers that tell browsers how to behave. They reduce common attacks like XSS, clickjacking, MIME sniffing, and data leakage. In a Rust/Actix backend, the clean way is to apply these headers using middleware, so every response gets the same secure defaults without repeating code in each handler.

In this blog, you will build a custom Security Headers middleware and wire it into main.rs. You’ll also see the request flow: middleware runs, handler executes, DB query runs, then middleware adds headers to the response.

1) What are security headers?
What

Security headers are response headers that enforce browser security rules.

Why

They reduce risk from:

Cross-site scripting (XSS)

Clickjacking (UI redress attacks)

MIME-type sniffing (wrong content treated as executable)

Referrer leakage

Insecure resource loading

When

Use security headers on:

All API responses (safe defaults)

Any server that serves HTML pages or assets

Admin dashboards and user-facing sites

Even if you return JSON only, these headers are still beneficial.

2) Request flow (middleware → handler → DB → middleware)

A secure request looks like this:

Client calls GET /api/shops

Middleware receives request

Middleware forwards request to handler

Handler checks session and calls DB

Handler returns JSON response

Middleware adds security headers to response

Response goes back to client

This ensures every response is protected automatically.

3) Step 1: Decide which headers to set

Below is a good production default:

✅ X-Content-Type-Options: nosniff
Prevents MIME sniffing.

✅ X-Frame-Options: DENY
Blocks clickjacking (no iframe embedding).

✅ Referrer-Policy: no-referrer (or strict-origin-when-cross-origin)
Reduces referrer leakage.

✅ Permissions-Policy: ...
Disables browser features you don’t use (camera, mic, etc).

✅ Strict-Transport-Security (HSTS)
Force HTTPS, but only in production with real TLS.

✅ Content-Security-Policy (CSP)
Powerful header for XSS control (more relevant when serving HTML). For pure JSON APIs you can still set a safe CSP, but it matters most when you return pages.

4) Step 2: Create Security Headers middleware

Create file:

src/middleware/security_headers.rs

use actix_service::{Service, Transform};
use actix_web::{
    dev::{ServiceRequest, ServiceResponse},
    http::header::{HeaderName, HeaderValue},
    Error,
};
use futures_util::future::{ready, LocalBoxFuture, Ready};

#[derive(Clone)]
pub struct SecurityHeaders {
    // enable HSTS only in production
    pub enable_hsts: bool,
    // optional CSP if you serve HTML
    pub csp: Option<String>,
}

impl SecurityHeaders {
    pub fn new(enable_hsts: bool, csp: Option<String>) -> Self {
        Self { enable_hsts, csp }
    }
}

impl<S, B> Transform<S, ServiceRequest> for SecurityHeaders
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: 'static,
{
    type Response = ServiceResponse<B>;
    type Error = Error;
    type Transform = SecurityHeadersMiddleware<S>;
    type InitError = ();
    type Future = Ready<Result<Self::Transform, Self::InitError>>;

    fn new_transform(&self, service: S) -> Self::Future {
        ready(Ok(SecurityHeadersMiddleware {
            service,
            cfg: self.clone(),
        }))
    }
}

pub struct SecurityHeadersMiddleware<S> {
    service: S,
    cfg: SecurityHeaders,
}

impl<S, B> Service<ServiceRequest> for SecurityHeadersMiddleware<S>
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: 'static,
{
    type Response = ServiceResponse<B>;
    type Error = Error;
    type Future = LocalBoxFuture<'static, Result<Self::Response, Self::Error>>;

    fn call(&self, req: ServiceRequest) -> Self::Future {
        let cfg = self.cfg.clone();
        let fut = self.service.call(req);

        Box::pin(async move {
            let mut res = fut.await?;

            // 1) No MIME sniffing
            res.headers_mut().insert(
                HeaderName::from_static("x-content-type-options"),
                HeaderValue::from_static("nosniff"),
            );

            // 2) Block iframe embedding (clickjacking)
            res.headers_mut().insert(
                HeaderName::from_static("x-frame-options"),
                HeaderValue::from_static("deny"),
            );

            // 3) Reduce referrer leakage
            res.headers_mut().insert(
                HeaderName::from_static("referrer-policy"),
                HeaderValue::from_static("strict-origin-when-cross-origin"),
            );

            // 4) Browser features control
            res.headers_mut().insert(
                HeaderName::from_static("permissions-policy"),
                HeaderValue::from_static("camera=(), microphone=(), geolocation=(), payment=()"),
            );

            // 5) HSTS only for production HTTPS
            if cfg.enable_hsts {
                res.headers_mut().insert(
                    HeaderName::from_static("strict-transport-security"),
                    HeaderValue::from_static("max-age=31536000; includeSubDomains"),
                );
            }

            // 6) Optional CSP (mainly for HTML pages)
            if let Some(csp) = cfg.csp {
                if let Ok(v) = HeaderValue::from_str(&csp) {
                    res.headers_mut().insert(
                        HeaderName::from_static("content-security-policy"),
                        v,
                    );
                }
            }

            Ok(res)
        })
    }
}

2–3 simple lines about what this does

This middleware runs after your handler returns a response. It then injects security headers into every response automatically. This means you don’t need to add headers in each handler.

5) Step 3: Register middleware module

Create:


src/middleware/mod.rs

pub mod security_headers;
6) S*tep 4: Wire it into main.rs*

In main.rs:

mod middleware;
use middleware::security_headers::SecurityHeaders;

Enable HSTS only in production:

let is_production = std::env::var("APP_ENV").unwrap_or_default() == "production";

// If you serve only JSON, CSP can be optional.
// If you serve HTML templates, set a real CSP.

let csp = Some("default-src 'self'; frame-ancestors 'none'; base-uri 'self'".to_string());


HttpServer::new(move || {
    App::new()
        .app_data(state.clone())
        .wrap(cors)
        .wrap(
            SessionMiddleware::builder(CookieSessionStore::default(), key.clone())
                .cookie_secure(is_production)
                .cookie_same_site(SameSite::Lax)
                .build(),
        )
        // ✅ Security headers middleware
        .wrap(SecurityHeaders::new(is_production, csp.clone()))
        .service(
            web::scope("/api")
                .route("/shops", web::get().to(handlers::list_shops_handler))
                .route("/login", web::post().to(handlers::login))
        )
        .service(Files::new("/uploads", "./uploads"))
})
.bind(cfg.bind_addr)?
.run()
.await

Why .wrap(SecurityHeaders...) is placed here

Because it should apply to all responses under the app. Any handler that returns JSON will automatically include these security headers.

7) Step 5: Handler example that hits DB
handlers/shop.rs

use actix_session::Session;
use actix_web::{error, web, HttpResponse, Result};

use crate::db::{list_shops_by_vendor, AppState};
use super::common::{ensure_login_user_id, ApiResponse};

pub async fn list_shops_handler(
    state: web::Data<AppState>,
    session: Session,
) -> Result<HttpResponse> {
    // Auth check
    let user_id = ensure_login_user_id(&session)?;

    let vendor_id = i32::try_from(user_id).map_err(|_| error::ErrorBadRequest("User id invalid"))?;

    // DB call
    let shops = list_shops_by_vendor(&state.pool, vendor_id)
        .await
        .map_err(error::ErrorInternalServerError)?;

    // Response
    Ok(HttpResponse::Ok().json(ApiResponse {
        message: "Shops fetched".to_string(),
        data: shops,
    }))
}

DB function (example)

db/shop.rs

use sqlx::MySqlPool;

pub async fn list_shops_by_vendor(pool: &MySqlPool, vendor_id: i32) -> Result<Vec<Shop>, sqlx::Error> {
    let rows = sqlx::query_as::<_, Shop>("SELECT * FROM shops WHERE vendor_id = ?")
        .bind(vendor_id)
        .fetch_all(pool)
        .await?;

    Ok(rows)
}

8) Confirm headers in browser/network

Call:


curl -i http://127.0.0.1:8080/api/shops

You should see headers like:

X-Content-Type-Options: nosniff
X-Frame-Options: deny
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Strict-Transport-Security: max-age=31536000; includeSubDomains   (only production)
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'; base-uri 'self'

9) Production tips (important)
Use HSTS only when HTTPS is guaranteed

If you enable HSTS on a domain that sometimes serves HTTP, users may get locked out.

Be careful with CSP

If you serve frontend HTML, CSP needs to allow required scripts/styles. For API-only backend, CSP is optional.

Add Cache-Control: no-store for auth endpoints

For login/session sensitive endpoints:

res.headers_mut().insert(
    HeaderName::from_static("cache-control"),
    HeaderValue::from_static("no-store"),
);

Rate Limiting Middleware in Actix-Web (Rust)

rakesh kumar — Thu, 05 Mar 2026 13:58:40 +0000

What rate limiting does(What/When/Why/Flow of a rate-limited request)
Request flow (middleware → handler → DB → middleware)
Step 1: Decide which headers to set
Step 2: Create rate limiter middleware
Step 3: Wire middleware in main.rs
Step 4: Handler example (login) showing DB flow
Step 5: Make rate limiting stricter only for login (best practice)
Production notes (very important)
Practical Example

Rate limiting means “don’t allow one client to hit the same API too many times in a short time.” It protects your server from brute-force login attempts, abusive bots, and accidental traffic spikes. In session-based apps, rate limiting is especially useful for endpoints like /login, /register, /otp, /search, and any expensive DB query route.

In this blog, we’ll build a custom rate limiting middleware (no external service needed), wire it in main.rs, and show how it blocks requests before they reach handler + DB.

What rate limiting does

What

It limits requests per key (IP, user_id, or API token) per time window.

Why

Stops brute-force attacks on /login

Reduces DB load

Avoids abuse (spam, scraping)

Improves uptime

When

Always on login and OTP routes

On public listing endpoints that can be scraped

On file upload endpoints (to avoid storage abuse)

Flow of a rate-limited request
Request flow

Client hits /api/login

Middleware runs first

Middleware checks “how many requests from this key in last X seconds”

If allowed → request goes to handler → handler calls DB

If blocked → middleware returns 429 Too Many Requests and handler/DB never runs

3) Step 1: Add required dependencies

In Cargo.toml:

# For time + thread-safe shared state
chrono = "0.4"
tokio = { version = "1", features = ["sync"] }

(You already use tokio and chrono; if yes, no changes.)

4) Step 2: Create rate limiter middleware

Create file:

src/middleware/rate_limit.rs

This version implements a fixed window counter:

window: 60 seconds

max requests: 10 per window per IP per route (customizable)

use actix_service::{Service, Transform};
use actix_web::{
    dev::{ServiceRequest, ServiceResponse},
    error,
    http::StatusCode,
    Error, HttpResponse,
};
use chrono::Utc;
use futures_util::future::{ready, LocalBoxFuture, Ready};
use std::collections::HashMap;
use std::sync::Arc;
use tokio::sync::Mutex;

/// Simple in-memory rate limiter state.
/// Key example: "IP|METHOD|PATH"
#[derive(Clone)]
pub struct RateLimiter {
    pub state: Arc<Mutex<HashMap<String, Counter>>>,
    pub window_secs: i64,
    pub max_requests: u32,
}

#[derive(Debug, Clone)]
pub struct Counter {
    pub window_start: i64,
    pub count: u32,
}

impl RateLimiter {
    pub fn new(window_secs: i64, max_requests: u32) -> Self {
        Self {
            state: Arc::new(Mutex::new(HashMap::new())),
            window_secs,
            max_requests,
        }
    }
}

/// Middleware wrapper object
pub struct RateLimitMiddleware {
    limiter: RateLimiter,
}

impl RateLimitMiddleware {
    pub fn new(limiter: RateLimiter) -> Self {
        Self { limiter }
    }
}

impl<S, B> Transform<S, ServiceRequest> for RateLimitMiddleware
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: 'static,
{
    type Response = ServiceResponse<B>;
    type Error = Error;
    type Transform = RateLimitMiddlewareService<S>;
    type InitError = ();
    type Future = Ready<Result<Self::Transform, Self::InitError>>;

    fn new_transform(&self, service: S) -> Self::Future {
        ready(Ok(RateLimitMiddlewareService {
            service,
            limiter: self.limiter.clone(),
        }))
    }
}

pub struct RateLimitMiddlewareService<S> {
    service: S,
    limiter: RateLimiter,
}

impl<S, B> Service<ServiceRequest> for RateLimitMiddlewareService<S>
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: 'static,
{
    type Response = ServiceResponse<B>;
    type Error = Error;
    type Future = LocalBoxFuture<'static, Result<Self::Response, Self::Error>>;

    fn call(&self, req: ServiceRequest) -> Self::Future {
        let limiter = self.limiter.clone();

        // Identify client (basic: IP). If behind proxy, you’ll read X-Forwarded-For safely.
        let ip = req
            .connection_info()
            .realip_remote_addr()
            .unwrap_or("unknown")
            .to_string();

        // Per endpoint key
        let key = format!("{}|{}|{}", ip, req.method(), req.path());

        let fut = self.service.call(req);

        Box::pin(async move {
            let now = Utc::now().timestamp();

            // Check + update counter
            let mut map = limiter.state.lock().await;
            let counter = map.entry(key).or_insert(Counter {
                window_start: now,
                count: 0,
            });

            // Reset window if expired
            if now - counter.window_start >= limiter.window_secs {
                counter.window_start = now;
                counter.count = 0;
            }

            // Increment and decide
            counter.count += 1;

            if counter.count > limiter.max_requests {
                // Block request with 429
                let res = HttpResponse::build(StatusCode::TOO_MANY_REQUESTS).json(serde_json::json!({
                    "success": false,
                    "message": "Too many requests. Please try again later.",
                    "code": 429
                }));
                return Err(error::InternalError::from_response("", res).into());
            }

            // Allowed → continue
            fut.await
        })
    }
}

Notes (simple, practical)

This is in-memory rate limiting. It works well for single server.

For multi-server (multiple instances), you’d store counters in Redis (same logic, shared store).

5) Step 3: Wire middleware in main.rs

Create module file:

src/middleware/mod.rs

pub mod rate_limit;

Now in main.rs:

mod middleware;
use middleware::rate_limit::{RateLimiter, RateLimitMiddleware};

Add it to your app. Example: allow 10 requests per 60 seconds per IP per endpoint.

HttpServer::new(move || {
    let limiter = RateLimiter::new(60, 10);

    App::new()
        .app_data(state.clone())
        .wrap(cors)
        .wrap(
            SessionMiddleware::builder(CookieSessionStore::default(), key.clone())
                .cookie_secure(false)
                .cookie_same_site(SameSite::Lax)
                .build(),
        )
        // Rate limit runs before handlers
        .wrap(RateLimitMiddleware::new(limiter))
        .service(
            web::scope("/api")
                .route("/login", web::post().to(handlers::login))
                .route("/shops", web::get().to(handlers::list_shops_handler))
        )
        .service(Files::new("/uploads", "./uploads"))
})

Important middleware order

CORS and Session can be before rate limit.

Rate limit should be early enough that it blocks before heavy work.

6) Step 4: Handler example (login) showing DB flow
Handler

src/handlers/auth.rs (simplified)

use actix_session::Session;
use actix_web::{error, web, HttpResponse, Result};
use crate::db::{find_user_by_username, AppState};
use crate::models::LoginForm;
use super::common::ApiResponse;

pub async fn login(
    body: web::Json<LoginForm>,
    state: web::Data<AppState>,
    session: Session,
) -> Result<HttpResponse> {
    // If rate limit blocks, this handler will never run.

    let user = find_user_by_username(&state.pool, &body.username)
        .await
        .map_err(error::ErrorInternalServerError)?;

    if let Some(user) = user {
        let valid = user.password == body.password;
        if valid {
            session.insert("user_id", user.id).map_err(error::ErrorInternalServerError)?;
            session.insert("username", user.username.clone()).map_err(error::ErrorInternalServerError)?;
            session.insert("role", user.role.clone()).map_err(error::ErrorInternalServerError)?;

            return Ok(HttpResponse::Ok().json(ApiResponse {
                message: "Login successful".to_string(),
                data: true,
            }));
        }
    }

    Err(error::ErrorUnauthorized("Invalid credentials"))
}

DB function

src/db/user.rs

use sqlx::MySqlPool;

#[derive(sqlx::FromRow, Debug)]
pub struct DbUser {
    pub id: i64,
    pub username: String,
    pub password: String,
    pub role: String,
}

pub async fn find_user_by_username(
    pool: &MySqlPool,
    username: &str
) -> Result<Option<DbUser>, sqlx::Error> {
    let user = sqlx::query_as::<_, DbUser>(
        "SELECT id, username, password, role FROM users WHERE username = ? LIMIT 1"
    )
    .bind(username)
    .fetch_optional(pool)
    .await?;

    Ok(user)
}

7) Step 5: Make rate limiting stricter only for login (best practice)

Instead of limiting every route equally, you usually want:

/login: 5 requests / minute

/uploads: 10 requests / minute

/home/vehicles: higher limit (like 120/min)

Simple way: apply middleware to a specific scope

.service(
    web::scope("/api")
        // Public routes
        .route("/home/vehicles", web::get().to(handlers::list_home_vehicle_cards_handler))
        // Login scope rate limited stricter
        .service(
            web::scope("")
                .wrap(RateLimitMiddleware::new(RateLimiter::new(60, 5)))
                .route("/login", web::post().to(handlers::login))
        )
)

This keeps your site usable while protecting sensitive endpoints.

8) Production notes (very important)
In-memory limiter limitations

Works per server instance only.

If you run 3 servers, each has its own counters (rate limiting becomes weaker).

Production upgrade

Replace HashMap with Redis counter (shared store).

Same “key/window/count” logic, but stored in Redis.

Practical Example

=================env===============

API_RATE_LIMIT_PER_MINUTE=120
LOGIN_RATE_LIMIT_PER_MINUTE=10
CRUD_WRITE_RATE_LIMIT_PER_MINUTE=40

=========config.rs=====================

   pub api_rate_limit_per_minute: u32,
    pub login_rate_limit_per_minute: u32,
    pub crud_write_rate_limit_per_minute: u32,
impl AppConfig {
    pub fn from_env() -> Self {
 let api_rate_limit_per_minute = env::var("API_RATE_LIMIT_PER_MINUTE")
            .ok()
            .and_then(|v| v.parse::<u32>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(120);
        let login_rate_limit_per_minute = env::var("LOGIN_RATE_LIMIT_PER_MINUTE")
            .ok()
            .and_then(|v| v.parse::<u32>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(10);
        let crud_write_rate_limit_per_minute = env::var("CRUD_WRITE_RATE_LIMIT_PER_MINUTE")
            .ok()
            .and_then(|v| v.parse::<u32>().ok())
            .filter(|v| *v > 0)
            .unwrap_or(40);

==================main.rs=======================

 .service(
                web::scope("/api")
                    .wrap(middleware::RateLimit::per_minute(cfg.api_rate_limit_per_minute))
                    .service(
                        web::scope("")
                            .wrap(middleware::RateLimit::per_minute(cfg.login_rate_limit_per_minute))
                            .route("/login", web::post().to(handlers::login)),
                    )
 .service(
       web::scope("")
       .wrap(middleware::require_roles(&["user"]))
       .wrap(middleware::RateLimit::mutations_per_minute(
        cfg.crud_write_rate_limit_per_minute,
       ))

===========================mod.rs==================

pub mod auth_middleware;
pub mod rate_limit_middleware;
pub mod role_middleware;

pub use auth_middleware::AuthMiddleware;
pub use rate_limit_middleware::RateLimit;
pub use role_middleware::require_roles;

=================middleware=======================

use std::collections::HashMap;
use std::future::{ready, Ready};
use std::rc::Rc;
use std::sync::{Arc, Mutex};
use std::time::{Duration, Instant};

use actix_web::{
    body::{EitherBody, MessageBody},
    dev::{forward_ready, Service, ServiceRequest, ServiceResponse, Transform},
    http::header::{HeaderValue, RETRY_AFTER},
    http::Method,
    Error, HttpResponse,
};
use futures_util::future::LocalBoxFuture;
use serde_json::json;

#[derive(Clone)]
struct WindowState {
    count: u32,
    window_start: Instant,
}

#[derive(Clone)]
pub struct RateLimit {
    max_requests: u32,
    window: Duration,
    entries: Arc<Mutex<HashMap<String, WindowState>>>,
    mode: LimitMode,
}

#[derive(Clone, Copy)]
enum LimitMode {
    All,
    MutationsOnly,
}

impl RateLimit {
    pub fn per_minute(max_requests: u32) -> Self {
        Self {
            max_requests,
            window: Duration::from_secs(60),
            entries: Arc::new(Mutex::new(HashMap::new())),
            mode: LimitMode::All,
        }
    }

    pub fn mutations_per_minute(max_requests: u32) -> Self {
        Self {
            max_requests,
            window: Duration::from_secs(60),
            entries: Arc::new(Mutex::new(HashMap::new())),
            mode: LimitMode::MutationsOnly,
        }
    }

    fn client_key(req: &ServiceRequest) -> String {
        req.connection_info()
            .realip_remote_addr()
            .map(|s| s.to_string())
            .or_else(|| req.peer_addr().map(|a| a.ip().to_string()))
            .unwrap_or_else(|| "unknown".to_string())
    }

}

impl<S, B> Transform<S, ServiceRequest> for RateLimit
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: MessageBody + 'static,
{
    type Response = ServiceResponse<EitherBody<B>>;
    type Error = Error;
    type InitError = ();
    type Transform = RateLimitService<S>;
    type Future = Ready<Result<Self::Transform, Self::InitError>>;

    fn new_transform(&self, service: S) -> Self::Future {
        ready(Ok(RateLimitService {
            service: Rc::new(service),
            max_requests: self.max_requests,
            window: self.window,
            entries: self.entries.clone(),
            mode: self.mode,
        }))
    }
}

pub struct RateLimitService<S> {
    service: Rc<S>,
    max_requests: u32,
    window: Duration,
    entries: Arc<Mutex<HashMap<String, WindowState>>>,
    mode: LimitMode,
}

impl<S, B> Service<ServiceRequest> for RateLimitService<S>
where
    S: Service<ServiceRequest, Response = ServiceResponse<B>, Error = Error> + 'static,
    B: MessageBody + 'static,
{
    type Response = ServiceResponse<EitherBody<B>>;
    type Error = Error;
    type Future = LocalBoxFuture<'static, Result<Self::Response, Self::Error>>;

    forward_ready!(service);

    fn call(&self, req: ServiceRequest) -> Self::Future {
        let service = self.service.clone();
        let max_requests = self.max_requests;
        let window = self.window;
        let entries = self.entries.clone();
        let mode = self.mode;

        Box::pin(async move {
            if matches!(mode, LimitMode::MutationsOnly)
                && !matches!(
                    *req.method(),
                    Method::POST | Method::PUT | Method::PATCH | Method::DELETE
                )
            {
                let response = service.call(req).await?;
                return Ok(response.map_into_left_body());
            }

            let key = RateLimit::client_key(&req);
            let now = Instant::now();

            let mut retry_after_secs = 0u64;
            let allowed = {
                let mut map = entries.lock().expect("rate_limit mutex poisoned");

                // Opportunistic cleanup to keep memory bounded for inactive clients.
                map.retain(|_, state| now.duration_since(state.window_start) < window);

                let state = map.entry(key).or_insert(WindowState {
                    count: 0,
                    window_start: now,
                });

                if now.duration_since(state.window_start) >= window {
                    state.count = 0;
                    state.window_start = now;
                }

                if state.count >= max_requests {
                    retry_after_secs = window
                        .saturating_sub(now.duration_since(state.window_start))
                        .as_secs()
                        .max(1);
                    false
                } else {
                    state.count += 1;
                    true
                }
            };

            if !allowed {
                let mut response = HttpResponse::TooManyRequests().json(json!({
                    "message": "Too many requests. Please try again later."
                }));
                response
                    .headers_mut()
                    .insert(RETRY_AFTER, HeaderValue::from_str(&retry_after_secs.to_string()).unwrap_or_else(|_| HeaderValue::from_static("60")));

                return Ok(req.into_response(response).map_into_right_body());
            }

            let response = service.call(req).await?;
            Ok(response.map_into_left_body())
        })
    }
}