Backend Integration Snippets

AI Prompt Template

Generate backend code for [feature].
- Language: [PHP/Node.js/Python/Go]
- Framework: [Laravel/Express/Flask/None]
- Database: [MySQL/PostgreSQL/MongoDB]
- Feature: [Detailed description]

Output: complete code, database design, API docs, error handling, security notes.

PHP Contact Form Handler

<?php
header("Content-Type: application/json");
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
    http_response_code(405);
    echo json_encode(["error" => "POST only"]);
    exit;
}
$name = trim($_POST["name"] ?? "");
$email = trim($_POST["email"] ?? "");
$message = trim($_POST["message"] ?? "");
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    http_response_code(400);
    echo json_encode(["error" => "Invalid email"]);
    exit;
}
mail("[email protected]", "Message from $name", $message, "From: $email");
echo json_encode(["success" => true]);
?>

Nginx Reverse Proxy for API

location /api/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Where Backend Integration Goes Wrong

Backend integration is the glue between your frontend and database. In theory it's simple: receive a request, query data, return results. In practice, 80% of production incidents happen in this layer.

It's not that backend code is inherently difficult. It's that edge cases go unhandled.

Three Layers of Defense

Layer 1: Input Validation

Never trust data from the client. This isn't about suspicion — it's a fundamental engineering assumption.

// Not recommended
$email = $_POST["email"];

// Recommended
$email = filter_var(trim($_POST["email"] ?? ""), FILTER_VALIDATE_EMAIL);
if ($email === false) {
    http_response_code(400);
    echo json_encode(["error" => "Invalid email format"]);
    exit;
}

Layer 2: Error Handling

Interfaces will fail. The question is whether the failure is informative.

Standard error response:

{
  "success": false,
  "error": {
    "code": "RATE_LIMIT",
    "message": "Too many requests. Retry in 30 seconds.",
    "request_id": "req_abc123"
  }
}

A single request_id solves the "user says something broke but you have no idea what happened" problem. Ask users to include it when reporting issues.

Layer 3: Retry Strategy

Separate retryable errors (502, 503, 504, 429) from non-retryable ones (400, 401, 403). For retryable errors, use exponential backoff:

Retry 1: wait 1 second
Retry 2: wait 2 seconds
Retry 3: wait 4 seconds
Max: 3 retries

API Design Principles

Versioning

Once an endpoint is live, never change the meaning of existing fields. Breaking changes go in a new version:

/api/v1/orders
/api/v2/orders

Timeouts

For requests taking longer than 2 seconds, return a task ID and let the frontend poll. Users won't wait for a response that takes more than 3 seconds.

Security Baseline

Every backend endpoint needs three checks:

  1. Authentication: who is this request from?
  2. Authorization: does this user have permission?
  3. Rate limiting: is this request within normal frequency?

Missing any one of these leaves your API vulnerable to abuse.

Closing Thought

Good backend code isn't the code with the most features. It's the code that gives clear, actionable feedback in every error scenario. When designing an API, ask yourself "what will the user see if this goes wrong?" — and your quality will improve dramatically.