Front‑End and Back‑End Collaboration Guidelines and Best Practices

The article begins by explaining the growing gap between front‑end and back‑end teams in a front‑back separation development model and why a clear collaboration specification is essential to improve efficiency and reduce communication costs.

Collaboration Process : A visual workflow is described, including requirement import, interface design, technical review, parallel development with mock data, and development‑environment integration.

API Specification :

Pre‑agreement on URL and request method; POST must use application/json.

Consistent naming, string type for IDs, unified time format (13‑digit timestamp), and amount in cents.

Request parameters should be consistent across similar fields; response should be null‑safe (empty array [] or object {} for empty lists) and include only necessary fields.

Enumerations should provide both Chinese and English descriptions.

Typical Bad Cases and Solutions :

1. Excessive front‑end conditional logic

// Button display logic example
{((record.state === 'RESULT_CONFIRM' && isCurrentUserCreate) || (record.state === 'RESULT_CHECK' && isCurrentUserCreate && currentUserCanCheck)) && <Button>确认</Button>}

Solution: Move complex display decisions to the back‑end and return a simple array of button definitions.

2. Over‑processing of data on the front‑end

Solution: Back‑end should provide fully integrated data to avoid re‑assembly on the client.

3. Front‑end maintained enum values

Solution: Backend supplies enum options; front‑end only renders them.

4. PC‑centric data structures unsuitable for mobile apps

Solution: Backend creates dedicated APIs for app scenarios.

5. Inconsistent field naming across the same business domain

Solution: Maintain a shared field dictionary between front‑end and back‑end.

6. Amount calculations performed on the front‑end before persisting

Solution: Only display‑only calculations stay on the front‑end; any persisted calculation must be done by the back‑end.

7. Front‑end business‑configuration validation logic

// Example validation request payload
{
  "code": "99900",
  "identity": "11111",
  "datas": [
    {"key": "catalog", "value": "A07"},
    {"key": "assetApproval", "value": 0}
  ]
}

Solution: Centralize validation in a back‑end service.

8. Directly calling other business‑line APIs

Solution: Each business line should expose its own consolidated API to avoid cross‑line coupling.

9. Inconsistent pagination response formats

// Unified pagination format example
{
  "result": {
    "data": [],
    "total": 0,
    "pageSize": 10,
    "pageNo": 1
  }
}

Solution: Adopt a single response schema (as shown above).

10. Splitting a single logical operation into multiple back‑end endpoints

Solution: Merge validation and submission into one endpoint and differentiate blocking vs. advisory errors in the response.

Effects : Implementing these standards reduces communication overhead, shortens integration time, speeds up testing, and simplifies online issue diagnosis.

Conclusion : When front‑end code contains excessive business logic, it signals a missing or weak collaboration specification; aligning responsibilities and adhering to the guidelines leads to smoother development and better product quality.