What are the application scenarios and practical tips of whistle in actual development?

Answer

Whistle has many practical application scenarios in actual development, which can greatly improve development efficiency and problem troubleshooting capabilities.

Common Application Scenarios

1. Local Development Debugging

Scenario Description: During frontend development, you need to call backend interfaces, but the backend service is running locally, requiring mapping online domain names to local services.

Solution:

shell
# Map online domain to local service
www.example.com host 127.0.0.1:3000
api.example.com host 127.0.0.1:3001

# Or use forward operator
www.example.com forward http://127.0.0.1:3000

Advantages:

• No need to modify domain names in code
• Quickly switch between local and online environments
• Facilitate frontend-backend joint debugging

2. Solve Cross-Origin Issues

Scenario Description: Encounter cross-origin issues during frontend development, need to add CORS response headers.

Solution:

shell
# Add CORS response headers
www.example.com resHeaders://{cors-headers.json}

cors-headers.json:

json
{
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type, Authorization"
}

Advantages:

• No need for backend to modify code
• Quickly solve cross-origin issues
• Suitable for development environment

3. Interface Data Mocking

Scenario Description: Backend interfaces are not yet developed, frontend needs to develop features first, requiring simulated interface return data.

Solution:

shell
# Mock user interface
www.example.com/api/user resBody://{mock-user.json}

# Mock list interface
www.example.com/api/list resBody://{mock-list.json}

# Use script to dynamically generate data
www.example.com/api/dynamic resScript://{dynamic-mock.js}

mock-user.json:

json
{
  "code": 0,
  "data": {
    "id": 1,
    "name": "Zhang San",
    "age": 25
  }
}

Advantages:

• Parallel frontend and backend development
• Improve development efficiency
• Easy to test various scenarios

4. Multi-Environment Switching

Scenario Description: Need to quickly switch between development, testing, and production environments to test functions in different environments.

Solution:

Create configuration files for different environments:

rules-dev:

shell
www.example.com host 127.0.0.1:3000
api.example.com host 127.0.0.1:3001

rules-test:

shell
www.example.com host test.example.com
api.example.com host api-test.example.com

rules-prod:

shell
www.example.com host prod.example.com
api.example.com host api-prod.example.com

Switch environments:

bash
# Switch to development environment
w2 restart -f rules-dev

# Switch to test environment
w2 restart -f rules-test

# Switch to production environment
w2 restart -f rules-prod

Advantages:

• Quickly switch environments
• Avoid modifying code
• Improve testing efficiency

5. Performance Optimization Testing

Scenario Description: Need to test website performance and find performance bottlenecks.

Solution:

shell
# Enable gzip compression
www.example.com resHeaders://{compression-headers.json}

# Set cache strategy
www.example.com/static/* resHeaders://{cache-headers.json}

# Simulate slow network
www.example.com resScript://{slow-network.js}

slow-network.js:

javascript
module.exports = function(req, res) {
  setTimeout(() => {
    res.end(JSON.stringify({ code: 0, data: 'success' }));
  }, 2000); // 2 second delay
};

Advantages:

• Simulate real network environment
• Discover performance issues
• Optimize user experience

6. Mobile Debugging

Scenario Description: Need to debug web applications or hybrid applications on mobile devices.

Solution:

1. Configure mobile proxy

   • Connect phone and computer to same Wi-Fi
   • Configure mobile proxy to point to computer IP and whistle port
   • Install HTTPS certificate

2. Add mobile-specific rules

shell
# Mobile interface mocking
m.example.com/api/user resBody://{mobile-mock-user.json}

# Mobile CORS handling
m.example.com resHeaders://{cors-headers.json}

Advantages:

• Real device testing
• Capture mobile network requests
• Solve mobile-specific issues

7. Interface Error Simulation

Scenario Description: Need to test application handling of various error situations, such as network errors, server errors, etc.

Solution:

shell
# Simulate 500 error
www.example.com/api/error resBody://{"code":500,"message":"Server Error"}

# Simulate timeout
www.example.com/api/timeout resScript://{timeout.js}

# Simulate network error
www.example.com/api/network-error resScript://{network-error.js}

timeout.js:

javascript
module.exports = function(req, res) {
  // Don't return response, simulate timeout
  setTimeout(() => {
    // Optional: return timeout error
    res.statusCode = 408;
    res.end(JSON.stringify({ code: 408, message: 'Request Timeout' }));
  }, 30000);
};

Advantages:

• Test exception handling logic
• Improve application robustness
• Facilitate problem troubleshooting

8. Interface Data Modification

Scenario Description: Need to modify interface return data to test different data scenarios.

Solution:

shell
# Modify response data
www.example.com/api/user resScript://{modify-data.js}

# Replace response content
www.example.com resReplace://old-string/new-string

modify-data.js:

javascript
module.exports = function(req, res) {
  const originalEnd = res.end;
  
  res.end = function(chunk, encoding) {
    if (chunk) {
      const body = chunk.toString();
      const jsonData = JSON.parse(body);
      
      // Modify data
      jsonData.data.status = 'active';
      jsonData.data.timestamp = Date.now();
      
      originalEnd.call(res, JSON.stringify(jsonData), encoding);
    } else {
      originalEnd.call(res, chunk, encoding);
    }
  };
};

Advantages:

• Quickly test different data scenarios
• No need for backend modification
• Improve testing efficiency

9. Interface Request Modification

Scenario Description: Need to modify request parameters or request headers to test different request scenarios.

Solution:

shell
# Modify request headers
www.example.com reqHeaders://{custom-headers.json}

# Use script to modify request
www.example.com reqScript://{modify-request.js}

custom-headers.json:

json
{
  "X-Custom-Header": "Custom Value",
  "X-Request-ID": "12345"
}

modify-request.js:

javascript
module.exports = function(req, res) {
  // Add request parameters
  if (req.url.includes('/api/user')) {
    const separator = req.url.includes('?') ? '&' : '?';
    req.url += separator + 'debug=true';
  }
  
  // Modify request headers
  req.headers['X-Debug-Mode'] = 'true';
};

Advantages:

• Test different request scenarios
• Add debug information
• Facilitate problem troubleshooting

10. WebSocket Debugging

Scenario Description: Need to debug WebSocket connections and messages.

Solution:

shell
# WebSocket proxy
ws.example.com host 127.0.0.1:8080

# Use plugin to debug WebSocket
ws.example.com plugin://websocket-debugger

Advantages:

• Capture WebSocket messages
• Debug real-time communication
• Solve connection issues

Practical Tips

1. Grouped Rule Management

Use comments and grouping to manage large numbers of rules:

shell
# ==================== Local Development ====================
www.local.com host 127.0.0.1:3000
api.local.com host 127.0.0.1:3001

# ==================== Test Environment ====================
www.test.com host test.example.com
api.test.com host api-test.example.com

# ==================== Data Mocking ====================
www.example.com/api/user resBody://{mock-user.json}
www.example.com/api/list resBody://{mock-list.json}

2. Quickly Enable/Disable Rules

Add # before rules to quickly disable them:

shell
# www.example.com host 127.0.0.1:3000  # Disabled
www.example.com host test.example.com  # Enabled

3. Use Values Files

Create Values files to store common configurations:

values.json:

json
{
  "local-ip": "127.0.0.1",
  "local-port": "3000",
  "test-host": "test.example.com"
}

Use in rules:

shell
www.example.com host {{local-ip}}:{{local-port}}

4. Export and Import Configuration

Regularly export configuration files for backup and sharing:

bash
# Export configuration
cp ~/.whistle/rules ~/backup/whistle-rules-$(date +%Y%m%d)

# Import configuration
cp ~/backup/whistle-rules-20240101 ~/.whistle/rules

Best Practices

1. Regularly Backup Configuration

   • Avoid configuration loss
   • Facilitate rollback

2. Use Version Control

   • Use Git to manage configuration files
   • Facilitate team collaboration

3. Add Clear Comments

   • Explain rule purpose
   • Facilitate maintenance

4. Regularly Clean Rules

   • Delete unused rules
   • Keep configuration concise

5. Security Considerations

   • Don't use on public networks
   • Close proxy after debugging
   • Protect certificate security