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:

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
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

Regularly Backup Configuration
- Avoid configuration loss
- Facilitate rollback
Use Version Control
- Use Git to manage configuration files
- Facilitate team collaboration
Add Clear Comments
- Explain rule purpose
- Facilitate maintenance
Regularly Clean Rules
- Delete unused rules
- Keep configuration concise
Security Considerations
- Don't use on public networks
- Close proxy after debugging
- Protect certificate security