DIY Rental Platform — Public Marketplace (Astro)

Summary

This is the anonymous, SEO-critical public face of the Malaysian rental marketplace — a new Astro 7 app at rent.gremlin.my that server-renders every page, reads Go directly for public data, and ships no island framework at all. Slice 1 proves owners will list and slice 2 proves the two sides will transact; without this app, both are a private tool.

• Domain rent.gremlin.my → panel.gremlin.my
• Stack Astro 7 + Cloudflare adapter, zero integrations
• Audience Seekers — signed out, arriving from Google or WhatsApp
• Covers Slice 1 step 8, slice 2 step 9 — no OpenSpec change
• New ADRs 0056 (product boundary), 0057 (immutable slugs)
• Hard dependency Four contract items must land before slice 1's fixture freezes

A Seeker — someone with no account — finds a Malaysian rental listing through Google, browses and filters without a page reload, and clicks through to arrange a viewing.

Success criteria

• A listing detail page is indexable and renders a correct card when shared on WhatsApp
• Filtering does not reload the page, and every result set has a shareable URL
• No public page ever renders an owner name, phone, email, or exact street address
• The site still serves a useful page when the API is down
• A URL that was ever indexed or shared keeps resolving — slugs never change (ADR-0057)
• Clicking "Arrange Viewing" lands on the booking form for that listing, even though the Seeker has to create an account on the way

Architecture at a glance

flowchart TD
    seeker["Seeker · signed out"] --> edge["Cloudflare edge · cached HTML"]
    edge --> ssr["Astro SSR on Workers"]
    ssr --> api["rental-api.ts · the only fetch caller"]
    api --> go["Go · GET /api/public/rental/listings"]
    ssr --> img["/cdn-cgi/image · edge resize"]
    img --> r2["R2 public photo prefix"]
    edge -.->|"Arrange Viewing"| panel["panel.gremlin.my/tenant/book/{slug}"]
    panel --> auth["Better Auth sign-up · slug preserved"]
    auth --> book["Booking form · Seeker becomes Tenant"]
    

Data flow

browser ──► Cloudflare edge (cached HTML)
              └─► Astro SSR on Workers
                    └─► GET {RENTAL_API_URL}/api/public/rental/listings?…
                        RENTAL_API_URL = https://api.kokweng.net   (origin only)

One module, src/lib/rental-api.ts, exports searchListings(params) and getListing(slug). They own path constants, query-string building, a fetch timeout, and response typing. No page calls fetch directly.

App layout

apps/rental/
  astro.config.mjs            ASTRO_ADAPTER pattern, copied from quiz; no integrations
  src/
    layouts/Layout.astro      ClientRouter + prefetch
    pages/
      index.astro
      property/[slug].astro
      sitemap.xml.ts
      404.astro
      unavailable.astro       rendered for the 503 degraded state
    components/
      FilterForm.astro        <form method="GET"> + inline requestSubmit() on change
      ListingCard.astro
      PhotoGallery.astro      CSS scroll-snap + anchors, no JavaScript
    lib/
      rental-api.ts           the only module that calls fetch
      areas.ts                allowlist of indexable areas
      image.ts                /cdn-cgi/image URL builder

Pages are / (search form + results), /property/{slug} (listing detail), /sitemap.xml, and a static /robots.txt. Filters live entirely in the query string: ?area=&min_rent=&max_rent=&type=&furnishing=&page=

Key decisions

What the repository already decided

Five findings from exploring frontend/astro and slice 1's schema, three of which correct the slice 1 design.

Scope

In scope

• New app frontend/astro/apps/rental, node adapter for dev and Cloudflare for build, copying the ASTRO_ADAPTER pattern quiz and platform already use
• ADR-0056 recording the product boundary and the direct-to-Go exception
• Search page: area, price range, property type, furnishing
• Listing detail at /property/{slug}, with photos, terms, house rules, and the "Direct from Owner" badge
• "Arrange Viewing" linking into the panel's booking entry route from slice 2
• SEO: per-listing titles and descriptions, Open Graph, canonical URLs, JSON-LD, sitemap.xml, robots.txt
• Cache headers so Cloudflare serves repeat traffic, including stale-if-error
• A degraded state when the API is unavailable
• Edge image resizing through /cdn-cgi/image so 5MB owner photos do not ship as-is
• A curated allowlist of indexable areas, also used to build the filter dropdown
• Cloudflare Web Analytics plus one "Arrange Viewing" click event

Out of scope, by decision

Any authenticated page, Seeker accounts, saved listings and favourites, map view, mortgage calculators, agent listings, hand-written area landing pages, review or rating display, languages beyond English, GA4 or any cookie-based analytics, and any Bun proxying.

Deliberately not handled

Cache purging

Suspending a listing leaves its public page warm for up to five minutes. No purge call is built.

A slug enumeration endpoint

The sitemap pages through the existing paginated API.

Upgrading the three existing Astro apps

They stay on 6 until someone upgrades them deliberately.

Normalizing area

The allowlist contains the blast radius without touching slice 1's schema. A reference table is the upgrade path.

Slug redirects

Slugs are immutable (ADR-0057), so no history table and no 301 handling exists. That is what makes it safe to have none.

Caching

Search gets the shorter window because filter combinations multiply cache entries and each is cheap to regenerate. Detail pages are the ones worth holding.

SEO and the indexing rule

• Per-listing title and description built from the listing — for example "3-bedroom condo for rent in Petaling Jaya — RM2,000/month" — with the description drawn from the owner's text and truncated.
• Open Graph tags carrying the cover photo, so a WhatsApp share renders a card. In this market that is a real traffic source.
• JSON-LD RealEstateListing on each detail page.
• sitemap.xml generated from live listings and cached an hour.
• robots.txt allowing everything and pointing at the sitemap.

Slice 1's public API is paginated and offers no way to ask for every live slug at once, so the sitemap route pages through until exhausted, with a hard cap. At current volume that is one request. A dedicated slugs endpoint on the Go side is the upgrade if listings ever reach the thousands.

Images

Resize at the edge

lib/image.ts builds /cdn-cgi/image/width=…,format=auto,… URLs over the public R2 photo URL. No build step, no image pipeline, no dependency.

Explicit dimensions

width and height on every <img>, taken from the new photo dimension columns, so the browser reserves the right box and CLS stays at zero.

srcset

A small fixed set of widths, so a phone does not download a desktop image.

Lazy loading

loading="lazy" everywhere except the LCP image — the first card's photo on /, and the cover photo on a detail page. Lazy-loading the LCP image delays the exact paint being measured.

Fallback

If /cdn-cgi/image turns out not to be available on the zone (verified in delivery step 1): cap photo dimensions at upload in slice 1 instead, and keep everything else unchanged.

What this design requires from slice 1

The Arrange Viewing handoff

This is the one conversion moment in the product, and it is where a Seeker becomes a Tenant. Every Seeker is signed out by definition, so the click always meets a sign-up wall.

sequenceDiagram
    participant S as Seeker
    participant M as "rent.gremlin.my"
    participant P as "panel.gremlin.my"
    participant A as Better Auth
    S->>M: Views /property/{slug}
    S->>P: Clicks "Arrange Viewing" → /tenant/book/{slug}
    P->>P: Store {slug} before redirect
    P->>A: Redirect to sign-in / sign-up
    A-->>P: Session created
    P->>P: Return to /tenant/book/{slug}
    P->>P: Resolve slug
    alt Slug resolves
        P-->>S: Booking form → viewing request created → Seeker becomes Tenant
    else Slug is gone (suspended within cache window)
        P-->>S: "This property is no longer available" + link back
    end
    

This app's side

• The button keeps the label "Arrange Viewing". Alternative considered: "Sign up to arrange viewing" — rejected, it advertises friction on the page whose job is to create interest. The click event is what tells us whether that friction is actually costing conversions.
• It links to https://panel.gremlin.my/tenant/book/{slug} — the specific listing, not a list.

What slice 2 must add

1. A /tenant/book/{slug} route

   Slice 2 currently has only /tenant/requests, which is a list — landing an anonymous person there loses the property they came for.

2. Slug survives the sign-up round trip

   The Seeker must return to that exact route afterwards. Same registrable domain, so this is same-site state, not a cross-domain problem.

3. A "no longer available" state

   The route resolves the slug on load and, when it no longer resolves, shows "This property is no longer available" with a link back to rent.gremlin.my — never a raw 404. This is the visible symptom of the "no cache purge" trade-off; the design accepts the staleness, and this is where it gets handled.

Privacy boundary and error handling

Measurement

Nothing else in this design tells you whether it worked, and without that you cannot tell a listings-supply problem from a tenant-demand problem.

• Cloudflare Web Analytics — one script tag, free, cookieless, so it raises no PDPA consent obligation and needs no consent banner.
• One custom event on the "Arrange Viewing" click, which is the number that matters: it separates "nobody visits" from "people visit but will not sign up", and it is what decides whether rendering the booking form before requiring an account is ever worth building.
• GA4 is out of scope by decision. It drags in cookie consent obligations this site does not otherwise have.

If custom events turn out not to be available on Cloudflare Web Analytics, the fallback is to record the missing measurement as a known gap rather than to add a heavier analytics stack for one number.

Testing

• rental-api.ts unit tests — query building, response parsing, timeout behaviour, and error shape, against a stub server. Follows the existing apps/quiz/src/middleware.test.ts precedent.
• Leak test — render a listing detail and assert no phone, email, owner name, or exact address_line appears in the HTML.
• Contract-drift test — rental-api.ts added to slice 1's public golden fixture client list, asserting client ⊆ Go (ADR-0052 pattern).
• Indexing rule unit test — the function that decides index vs noindex, follow, covering: bare /, allowlisted area alone, non-allowlisted area alone, area plus any second filter, and page=2. This rule is invisible in the rendered page and easy to break silently, which is exactly what makes it worth a test.
• One Playwright happy path — land on /, filter by area, open a listing, and confirm "Arrange Viewing" points at panel.gremlin.my/tenant/book/{slug}.

Deliberately not: visual regression, Lighthouse CI, a cross-browser matrix.

Delivery order

1. Scaffold apps/rental

   Astro 7 + Cloudflare adapter, deployed on rent.gremlin.my. Doubles as the four-way spike above.

2. ADR-0056 and ADR-0057

   Done — both written before implementation rather than during it.

3. rental-api.ts and its unit tests

   Built against a stub.

4. Search page

   Filter form, results, empty state.

5. Layout with ClientRouter and prefetch

   Gives no-reload navigation.

6. Listing detail

   Photo gallery, leak test.

7. SEO

   Titles, Open Graph, canonical rules, noindex on non-allowlisted filters, JSON-LD, robots.txt, sitemap.xml.

8. Cache headers and the degraded state
9. "Arrange Viewing" link into the panel
10. Playwright happy path, deploy

Verifications and open questions

All 22 questions this design opened were settled in a grilling session on 2026-08-26, and the resolutions are folded into the sections above. What is left is not a question but a list of things delivery step 1 verifies, each with a fallback already written down.