一键导入
image-resizing-service
Serve right-sized image variants to mobile via URL-based transforms and a CDN. Use when designing the image delivery path for a mobile app.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Serve right-sized image variants to mobile via URL-based transforms and a CDN. Use when designing the image delivery path for a mobile app.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | image-resizing-service |
| description | Serve right-sized image variants to mobile via URL-based transforms and a CDN. Use when designing the image delivery path for a mobile app. |
Mobile screens need many sizes: thumbnails, feed cards, full-screen, Retina. Shipping originals is wasteful and slow. A resizing service plus a CDN in front gives you bandwidth savings and good cache hit rates.
A. Pre-generated variants (batch). At upload time, a worker produces a fixed set of sizes and formats. Clients request specific variant URLs.
Pros: low runtime cost, deterministic storage, easy to cache. Cons: you pay for every size whether it is requested or not; adding a new size requires a backfill.
B. On-demand transforms (URL-based). A single origin; clients append transform params; the edge transforms and caches.
Pros: flexible, no backfill. Cons: first-request latency; requires a transform service (self-hosted imgproxy, thumbor, or managed imgix/Cloudinary/Cloudflare Images).
Most mobile apps benefit from a hybrid: pre-generate the handful of sizes used by the primary screens; enable on-demand for long-tail needs.
Design the URL so the client can ask for exactly what the device needs:
https://cdn.example.com/img/med_01HX7.../w=750,h=750,fit=cover,format=auto,q=80
w, h in CSS pixels (client multiplies by device scale).fit: cover, contain, fill, inside.format=auto lets the edge pick AVIF / WebP / JPEG based on Accept.q: quality, default 80; lower for thumbnails.dpr (device pixel ratio) optional alternative to pre-multiplied w/h.Allowlist permitted combinations -- attackers will otherwise request every size + format to blow up your cache.
Prefer format=auto and let the edge pick based on Accept headers:
Accept: image/avif,image/webp,image/*;q=0.8
Using imgproxy (Go) behind a CDN:
Client -> CDN -> imgproxy -> object storage
cache hit -> serve directly
imgproxy URL example (signed):
https://cdn.example.com/signature/rs:fill:750:750:1/q:80/format:webp/plain/s3://uploads/med_01HX7/original.jpg
Self-hosted alternative (Python/FastAPI + libvips):
from fastapi import FastAPI, Response
import pyvips
app = FastAPI()
@app.get("/img/{key:path}")
def img(key: str, w: int = 0, h: int = 0, q: int = 80, format: str = "webp"):
im = pyvips.Image.thumbnail(f"s3://uploads/{key}", w or h, height=h or None)
buf = im.write_to_buffer(f".{format}[Q={q}]")
return Response(buf, media_type=f"image/{format}",
headers={"Cache-Control": "public, max-age=31536000, immutable"})
Always process in a streaming, memory-bounded way; libvips is the right default for that. Restrict output dimensions (e.g., max 4096x4096) and decoded pixels to prevent DoS via huge inputs.
Cache-Control: public, max-age=31536000, immutable.iOS (SDWebImage / Nuke):
let url = imageURL(mediaId: id, width: view.bounds.width, fit: .cover)
imageView.nuke.load(url)
Android (Coil):
imageView.load(imageUrl(id, widthPx = view.width, fit = "cover")) {
crossfade(true)
placeholder(R.drawable.ph)
}
The helper imageUrl(...) computes device-scaled pixel dimensions and appends transform params. Keep that logic in one place.
For feed and list views, ship a tiny placeholder (BlurHash string, or a 16x16 WebP) in the JSON payload. The client renders that instantly while the full image streams:
{
"id": "med_01HX7...",
"w": 3024, "h": 4032,
"blurhash": "LEHV6nWB2yk8pyo0adR*.7kCMdnj"
}
Track cache hit rate by variant, p95 transform latency on miss, bytes delivered per platform, and format distribution over time. Alert when miss latency degrades -- usually a bad transform service config.
format=auto wired to Accept header negotiation.Cache-Control and CDN in front.When and how to use a Backend-for-Frontend (BFF) for mobile -- scoping, ownership, and anti-patterns. Use when deciding whether a BFF is justified or designing one.
GraphQL server design tuned for mobile -- persisted queries, batching, N+1 mitigation, and Apollo client integration. Use when building or reviewing a GraphQL API for mobile apps.
Design mobile-friendly HTTP APIs with predictable pagination, filtering, sorting, sparse/partial responses, and a consistent error envelope. Use when specifying new endpoints or reviewing existing ones for mobile use.
REST conventions tuned for mobile clients -- resources, HTTP caching, idempotency, and versioning. Use when designing or reviewing RESTful endpoints.
Server-side OAuth 2.1 + PKCE for native mobile apps -- authorization endpoint, token endpoint, refresh rotation, and device binding. Use when implementing or reviewing the auth server for mobile clients.
Model multi-device sessions on the backend with sliding vs absolute expiry, device listing, and remote logout. Use when building the session model or a "Your devices" screen.