Backend Integration

Backend Integration: Connecting Your Site's Front and Back

A website starts producing real value not when the pages look polished, but when forms actually capture data, logins verify identity, and payment callbacks land in the database. That is what backend integration is about. It matters especially for AI-generated sites: AI can produce a complete frontend quickly, but business logic, database reads and writes, and third-party service calls still have to be implemented on the backend.

Backend integration is the glue between your frontend and your database. Whether you follow the Node.js API example or a basic integration guide, it boils down to one sentence: accept the request, validate the input, process the business logic, return the result. That sounds simple, yet a large share of production incidents happen in exactly this layer. The root cause is rarely that the code cannot be written — it is that edge cases go unhandled.

A typical integration scenario

Say you are launching an event-registration site. You need three things: a registration form, an admin panel to list signups, and an automatic confirmation email after each registration. The frontend is already written in HTML and JavaScript, so the backend has to solve the three problems in this table:

If you are unsure which language to pick, read the Laravel backend guide, the Node.js Express guide or the Flask API example, then lock the stack with database selection. For interface conventions, see REST API design.

AI prompt template for backend code

The more detail you put into a prompt, the closer the generated backend code is to something usable. This template works as a starting point:

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.

One caveat: AI-generated code must be reviewed by a human. Check three things in particular: whether input validation is complete, whether every SQL statement is parameterized, and whether error messages leak internal paths.

A PHP contact form that actually works

Take the simplest "contact form" as an example. Production-ready PHP code does at least four things: only accept POST, validate the email format, cap the field length, and return JSON instead of HTML.

<?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;
}
if (strlen($message) > 2000) {
    http_response_code(400);
    echo json_encode(["error" => "Message too long"]);
    exit;
}
mail("[email protected]", "Message from $name", $message, "From: $email");
echo json_encode(["success" => true]);
?>

If you want the form to submit without a page reload, see the AJAX contact form walkthrough.

Nginx reverse proxy: exposing the API to the frontend

The backend often runs on a different port than the frontend, for example Node.js on 3000 and Nginx on 80. A reverse proxy forwards /api/ requests to the backend process:

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

The benefit: only ports 80/443 are exposed to the public, the backend process never touches the public internet directly, and you can add rate limiting, caching and access logs in one place. For the full site setup see Nginx site configuration, and pick a suitable server before going live.

API design: versioning, timeouts and a consistent response shape

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

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

Keep the response shape consistent so the frontend and debugging tools can parse it:

{
  "success": true,
  "data": { "order_id": "ORD-20260712-001" }
}

On errors, return a consistent shape with a request_id. When a user reports a problem, they only need to paste that ID and you can find the exact request in the logs:

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

For anything expected to take more than 2 seconds, return a task ID and let the frontend poll, instead of leaving the user staring at a loading screen.

Error handling and retry strategy

Separate retryable errors from non-retryable ones:

Retries use exponential backoff to avoid a thundering herd:

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

Security baseline: three mandatory checks

Every backend endpoint must pass three checks before going live:

1. Authentication: who is this request from? See JWT authentication.
2. Authorization: is this user allowed to perform the action?
3. Rate limiting: is the request within a normal frequency?

Missing any one of these leaves the API open to abuse. For the full picture, see website security best practices.

A real case: a registration page flooded by a script

A small company running an in-person event launched and received thousands of "registrations" on day one — most of them empty records submitted by a script from the same IP. The database filled up and the admin panel froze.

The post-mortem found three problems: no captcha on the form, no format validation on the backend, and no rate limiting on the endpoint. The fix was straightforward: a rate limit of 10 requests per minute per IP on the backend, a captcha on the frontend, and complete field validation. The problem never came back.

FAQ

Q: Can AI-generated backend code be used as-is?
A: Treat it as a first draft. Review input validation, SQL parameterization and error handling, and run edge cases in a test environment first.

Q: Do the frontend and backend have to be separated?
A: Not necessarily. A simple site can use PHP or server-side rendering; split them only when you need multiple clients or parallel development.

Q: How do I debug a 500 error?
A: Start with the request_id in your logs, confirm whether it is an input, permission or upstream problem, then decide whether to fix the code or retry.

References: PHP manual (https://www.php.net/ ), Nginx documentation (https://nginx.org/en/docs/ ), OWASP API Security Top 10 (https://owasp.org/API-Security/ )