0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · درس

المعالجة المسبقة واللاحقة باستخدام المرشحات

طبّقوا المرشحات لتنفيذ الإجراءات قبل وصول الطلب إلى الخدمة (pre) وبعد استجابة الخدمة (post).

المعالجة المسبقة واللاحقة باستخدام المرشحات درس مجاني في API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) على CoddyKit. هذا هو الدرس 3 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 4 دروس في المجموع.

بعض أجزاء هذا الدرس لم تُترجم بعد وتظهر باللغة الإنجليزية.

Intro to Pre/Post Filters

Welcome! In this lesson, we'll explore how Spring Cloud Gateway filters can process requests before they reach a backend service (pre-processing) and after the service responds (post-processing).

This fine-grained control is crucial for handling complex API gateway tasks.

The Filter Chain Revisited

Recall that filters operate in a chain. Each GatewayFilter or GlobalFilter can perform actions:

  • Before calling chain.filter(exchange): This is pre-processing.
  • After chain.filter(exchange) returns a Mono<Void>: This is post-processing.

The reactive nature of Spring Cloud Gateway, using Mono, makes this sequential execution powerful.

Pre-Processing: Before the Service

Pre-processing filters execute before the gateway forwards the request to your actual backend service. Think of them as interceptors for incoming requests.

Common pre-processing tasks include:

  • Authenticating and authorizing requests
  • Adding or modifying request headers
  • Rewriting the URL path or query parameters
  • Implementing rate limiting

Pre-Filter Example: Add Header

Let's look at a simple pre-processing example: adding a custom header to the request before it reaches the service. Spring Cloud Gateway provides built-in filters like AddRequestHeader for this.

This configuration adds an X-Request-Source header with the value gateway to all requests matching the path /api/pre/**.

spring:
  cloud:
    gateway:
      routes:
        - id: pre_header_route
          uri: http://localhost:8080/service/echo
          predicates:
            - Path=/api/pre/**
          filters:
            - AddRequestHeader=X-Request-Source, gateway

Runnable Pre-Filter Code

Try running this full Spring Boot application. It sets up a gateway that adds a request header and routes to a simple echo endpoint within the same application. Check the backend's console or response to see the added header!

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class GatewayApp {

  public static void main(String[] args) {
    SpringApplication.run(GatewayApp.class, args);
  }

  // Dummy backend service to echo headers
  @GetMapping("/service/echo")
  public String echoHeaders(@RequestHeader(required = false) java.util.Map<String, String> headers) {
    return "Backend received headers: " + headers.get("x-request-source");
  }

  @Bean
  public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
      .route("pre_header_route", r -> r.path("/api/pre/**")
        .filters(f -> f.addRequestHeader("X-Request-Source", "gateway"))
        .uri("http://localhost:8080/service/echo")) // Route to its own dummy backend
      .build();
  }
}

Post-Processing: After the Service

Post-processing filters execute after the backend service has responded but before the gateway sends that response back to the client.

This allows you to inspect or modify the backend's response.

Typical post-processing tasks include:

  • Modifying response headers or body
  • Logging response details (status, latency)
  • Adding metrics for response processing
  • Implementing response caching

Custom Post-Processing Filter

For post-processing, you often need to create custom filters. These filters use the Mono returned by chain.filter(exchange) to add logic that executes upon successful completion.

The .then(Mono.fromRunnable(() -> { ... })) pattern is common for post-processing actions.

Runnable Post-Filter Code

Here's a full Spring Boot application with a custom GlobalFilter that adds a X-Post-Processed header to every response. Notice how the filter logic is chained using .then(Mono.fromRunnable(...)).

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.core.Ordered;
import org.springframework.stereotype.Component;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@SpringBootApplication
@RestController
public class GatewayApp {

  public static void main(String[] args) {
    SpringApplication.run(GatewayApp.class, args);
  }

  // Dummy backend service
  @GetMapping("/service/data")
  public String getData() {
    return "Backend response data!";
  }

  @Bean
  public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
    return builder.routes()
      .route("post_filter_route", r -> r.path("/api/post/**")
        .uri("http://localhost:8080/service/data")) // Route to itself
      .build();
  }
}

@Component
class CustomPostFilter implements GlobalFilter, Ordered {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            // This code runs AFTER the downstream service responds
            exchange.getResponse().getHeaders().add("X-Post-Processed", "true");
            System.out.println("Post-processing: Added X-Post-Processed header.");
        }));
    }

    @Override
    public int getOrder() {
        return -1; // Execute relatively late in the filter chain
    }
}

Pre vs. Post: Key Differences

Understanding when to use pre vs. post processing is key:

  • Pre-filters: Act on the request before it leaves the gateway. Ideal for security, routing logic, request transformation.
  • Post-filters: Act on the response after it returns from the backend. Ideal for response transformation, logging response details, metrics collection.

Choose the right stage to efficiently manage your API traffic.

Filter Timing Challenge

Consider a Spring Cloud Gateway setup. Which of these tasks are typically performed by filters before forwarding a request to a backend service?

Recap: Pre/Post Processing

Great job! You've learned about the powerful concept of pre-processing and post-processing with Spring Cloud Gateway filters.

  • Pre-filters modify requests before they hit the backend.
  • Post-filters modify responses after the backend has replied.
  • The reactive Mono chain enables precise control over filter execution timing.

This understanding is vital for building robust and feature-rich API gateways!

الأسئلة الشائعة

هل درس «المعالجة المسبقة واللاحقة باستخدام المرشحات» مجاني؟

نعم — نص درس «المعالجة المسبقة واللاحقة باستخدام المرشحات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)، انتقل إلى CoddyKit PRO. تتضمن دورة API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) 4 دروس في المجموع.

ماذا ستتعلم في «المعالجة المسبقة واللاحقة باستخدام المرشحات»؟

طبّقوا المرشحات لتنفيذ الإجراءات قبل وصول الطلب إلى الخدمة (pre) وبعد استجابة الخدمة (post). تتمرن على API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)؟

لا تُشترط خبرة سابقة. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 3 من أصل 4.

كم من الوقت يستغرق درس «المعالجة المسبقة واللاحقة باستخدام المرشحات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) هذا؟

نعم. كل درس في API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. المرشحات العامة وGatewayFilterFactory
  2. مرشحات الطلبات والاستجابات المخصّصة
  3. المعالجة المسبقة واللاحقة باستخدام المرشحات
  4. ‏GatewayFilters المضمّنة التي ينبغي معرفتها
← العودة إلى API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)