BE33 : scope recipe discovery/filter to existing endpoints

[thoran123]

Goal

Clarify backend responsibility for recipe discovery, filtering, and user-created recipes — and implement only the backend capabilities that are truly needed. Refine what's already there instead of multiplying APIs.

Why it matters

Recipe features were trending toward parallel discovery / filter / utility endpoints. This PR locks the scope down in code and in docs so the team doesn't keep adding routes for things the frontend can do itself.

What changed

Refined existing endpoints (no new routes)

• GET /api/filter — cuisine_id, search, limit, offset are now applied server-side via Supabase (eq, ilike, range). % and _ are escaped in the search term. Dietary + allergy logic preserved. Response shape unchanged.
• GET /api/recipe/community — adds search, cuisine_id, cooking_method_id, sort (latest | oldest | name), limit, offset. Pagination is enforced via range() instead of pulling a giant slab and slicing in JS. Response gains a pagination block; existing fields are unchanged.

Tightened ownership on community share/unshare

• POST /api/recipe/:id/share-community and POST /api/recipe/:id/unshare-community now derive userId from req.user.userId only and ignore any user_id in the request body. Prevents a caller from submitting another user's recipe for community review. Returns 400 when there is no authenticated user.

User recipe create / update — intentionally not duplicated

• PATCH /api/recipe-library/:id remains the single update surface. No mirror endpoint added under /api/recipe/:id.
• model/createRecipe.js already pins new rows to visibility: "user_private" and is_published: false server-side, so the create flow is safe as-is.

Scope documented

• New docs/RECIPES_SCOPE.md lists what stays backend vs. what stays frontend, the discovery endpoint contract, ownership rules, and a checklist to apply before adding any new recipe route.

What was intentionally NOT added

• No parallel "discovery" endpoint — /api/filter and /api/recipe/community are the canonical surfaces.
• No mirror PATCH /api/recipe/:id — duplication of /api/recipe-library/:id.
• No tag / favourites / "print" / unit-conversion endpoints — those stay in the frontend.

Tests

New test/recipeDiscoveryAndFilter.test.js — 8 tests, all passing locally:

• cuisine_id push-down on /api/filter
• ILIKE escaping for % / _
• 400 on non-numeric cuisine_id
• community list: search, cuisine_id, sort, pagination push-down
• community list: default latest ordering
• share endpoint ignores body user_id, uses req.user.userId
• share returns 400 when unauthenticated
• unshare ignores body user_id, uses req.user.userId

Run: npx jest test/recipeDiscoveryAndFilter.test.js

Files changed

File	+/-
controller/filterController.js	+107 / −57
controller/recipeController.js	+73 / −9
docs/RECIPES_SCOPE.md	+111 (new)
test/recipeDiscoveryAndFilter.test.js	+370 (new)

Total: 4 files, +660 / −66

Risk

Low. No breaking changes to existing response shapes. New query params are all optional; existing clients keep working unchanged. Ownership tightening on share/unshare is a security improvement — clients that were sending user_id in the body still work, the body field is now just ignored.

Definition of Done

• Recipe discovery and user recipe flows are clearly scoped
• Existing recipe APIs are refined instead of multiplied
• Backend utility scope is intentionally limited and documented
• Tests added for the changed behavior

[TienNguyen3711]

I have checked and tested it. Approved