HooStore-UI/RUNNING.md
2026-10-27 15:09:07 +07:00

103 lines
3.6 KiB
Markdown

# Running the storefront
The storefront serves on <http://localhost:8000> and always talks to a backend
on <http://localhost:9000>. Two backends can fill that slot — the real Medusa
app or the bundled mock. **Only one at a time**: they both bind port 9000.
---
## Option A — real Medusa backend (recommended)
```bash
cd backend && yarn dev
```
```bash
cd frontend && yarn dev
```
`frontend/.env.local` must match that backend on two values, or the storefront
will not load:
| Variable | Why it must match |
|---|---|
| `NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY` | Every Store API call is rejected with `not_allowed` without a key the backend knows. `pk_test` is a placeholder that only works with the mock. |
| `NEXT_PUBLIC_DEFAULT_REGION` | Must be a country code the backend has a region for. The middleware redirects `/` to `/<countryCode>`; if the value has no region it falls back to whichever country comes first, which is rarely what you want. |
### Finding the publishable key
From the Medusa admin: **Settings → Publishable API keys**.
Or straight from the database:
```bash
cd backend && node -e "require('dotenv').config();const{Client}=require('pg');const c=new Client({connectionString:process.env.DATABASE_URL});c.connect().then(async()=>{const r=await c.query(\"select token from api_key where type='publishable' and revoked_at is null\");console.log(r.rows.map(x=>x.token).join('\n'));await c.end()})"
```
### Finding the valid region country codes
```bash
cd backend && node -e "require('dotenv').config();const{Client}=require('pg');const c=new Client({connectionString:process.env.DATABASE_URL});c.connect().then(async()=>{const r=await c.query('select iso_2 from region_country where region_id is not null');console.log(r.rows.map(x=>x.iso_2).join(', '));await c.end()})"
```
The backend currently configured here has a single **Europe** region (EUR)
covering `dk, fr, de, it, es, se, gb` — there is no `us`, so `.env.local` is
set to `dk`.
Also check `STORE_CORS` in `backend/.env` includes `http://localhost:8000`.
### After editing `.env.local`
Restart `yarn dev`. Next.js reads env files at boot.
---
## Option B — mock backend (no database)
`frontend/mock-backend/` is a small Node server implementing enough of the
Store API — regions, categories, collections, products, search and an
in-memory cart — for browsing and add-to-bag to work with no database.
```bash
cd frontend && yarn mock-backend
```
```bash
cd frontend && yarn dev
```
With the mock, `.env.local` wants `NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY=pk_test`
(the mock does not validate it) and `NEXT_PUBLIC_DEFAULT_REGION=us`.
Not emulated: checkout completion, payments, customer accounts, orders. Those
endpoints answer "nothing configured" so the storefront degrades gracefully
rather than erroring.
---
## Checks
```bash
cd frontend && yarn check
```
Runs `typecheck`, `lint` and `test`. `next build` also runs the type-check and
lint — they are no longer disabled in `next.config.js`, so a type error fails
the build.
Do not run `yarn build` while `yarn dev` is running: they share `.next` and the
build pulls the directory out from under the dev server.
---
## Branding
Everything user-visible that names the store lives in
[`src/lib/brand.ts`](src/lib/brand.ts) — wordmark, storage-key slug, tagline,
title helper and social links. Change `BRAND_NAME` and `BRAND_SLUG` there and
the whole storefront follows.
Footer copy for the informational pages lives in
[`src/lib/content/info-pages.ts`](src/lib/content/info-pages.ts); it is generic
boilerplate and should be replaced (or swapped for a CMS query) before launch.