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:
- Authentication: who is this request from?
- Authorization: does this user have permission?
- 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.