Files
backend/.cursor/rules/env-clients-deploy.mdc
T
Alireza HassaniandCursor 3faeb9bc0d Expand invoices with full templates, public viewer API, and account holder.
Add invoice template CRUD, key points/accounts, public GET endpoint, and migration 039 for account_holder_name.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-07-26 11:04:26 +03:30

35 lines
1.9 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
description: Environment split — websites always use remote API; dashboards use local API in dev and remote after deploy; coordinate backend + dashboard releases.
alwaysApply: true
---
# Backend ↔ dashboards ↔ websites
## Who talks to which API
| Client | Local development | After deploy (production) |
|--------|-------------------|---------------------------|
| **Business websites** (storefronts) | Still **remote** `https://api.meshkee.com` (or `https://api.{domain}`) | Same remote API |
| **Dashboards** (manage / business / customer) | **Local** backend (`localhost`) | **Remote** `https://api.meshkee.com` |
Websites never depend on a developers local API. Dashboards do during local work.
## Release coordination
Because deployed dashboards hit the **same** remote backend as production websites:
1. **Dashboard-facing API changes** (routes under auth/CMS/`businesses/:id/...` used by dashboards) must ship **backend + dashboards together** (or backend first only if fully backward-compatible with the currently deployed dashboards).
2. Do **not** deploy a dashboard that requires new backend fields/routes until that backend is live on `api.meshkee.com`.
3. Do **not** deploy a breaking backend change for dashboards until the matching dashboard build is ready to deploy in the same window.
4. **Website-facing** API changes go live for all storefronts as soon as the backend is deployed — keep `docs/website-api/` in sync (see `website-api-docs.mdc`). Prefer additive/backward-compatible changes when old websites may still be out.
## Practical order
```text
Compatible API add → deploy backend → deploy dashboards (can use new APIs)
Breaking API change → deploy backend + dashboards in one coordinated release
Website-only API → deploy backend (+ update website docs); websites pick it up from remote
```
Local dashboard work: run local backend; point dashboard env at local API. After merge/deploy, dashboards use remote API again.