Hi there! I’ve been exploring the legacy Webshop app (https://github.com/frappe/webshop) and noticed that many of its patterns pre‑date recent Frappe releases. If you were to rebuild it today, leveraging Frappe’s latest framework features, I’d love to understand your approach.
Below is a concise set of questions to guide the discussion; feel free to answer any or all of them. (I kept it short so it’s easy to skim.)
Quick technical snapshot of the current Webshop codebase
| Area | What the repo does today | Notes on security / coupling |
|---|---|---|
| Server calls | Heavy use of @frappe.whitelist functions—many are public (allow_guest=True) such as get_product_info_for_website ([GitHub][1]) |
These RPCs skip the normal DocType permission tree. |
| Permission bypass | Inside the cart flow the code frequently sets doc.flags.ignore_permissions = True (e.g., when creating / submitting a Quotation or Sales Order) ([GitHub][2]) |
This means any visitor who can hit the RPC can proceed as long as the business logic doesn’t raise its own checks. |
| REST usage | Almost no reliance on /api/resource/:doctype or the newer auto‑generated OpenAPI routes. All business logic is wrapped in the whitelisted Python functions. |
Probably a legacy choice (the code dates back to 2015‑2021) when the REST layer lacked granular hooks and atomic “cart” endpoints. |
| Frontend coupling | Jinja templates rendered server‑side (frappe.render_template(...)) are returned by the cart RPCs, so the browser gets HTML, not JSON. |
Makes it hard to adopt a modern SPA or headless storefront without rewriting. |
Why the pattern matters
-
Security:
‑ Relying onignore_permissionsand guest whitelists can accidentally expose mutations (e.g., address creation) that an unauthenticated user shouldn’t perform.
‑ Using DocType REST endpoints would inherit Frappe’s role‑based permission tree, rate‑limits, and field‑level rules automatically. -
Maintainability & Extensibility:
‑ Each RPC is a snowflake. Migrating to GraphQL or OpenAPI later means re‑implementing validations already present in the DocType schema.
‑ With REST you get CRUD, list filters, and meta information for free; you only need bespoke endpoints for true business transactions (checkout, payment capture, etc.). -
Frontend freedom:
‑ Moving to JSON‑only REST makes it trivial to mount React/Next.js or Vue/Nuxt storefronts, reuse the same API for mobile apps, and apply modern caching/CDN patterns.
Conversation starters for the Webshop maintainers
-
Permissions & Roles
- Would you keep using
@frappe.whitelist(allow_guest=True)or move to REST so DocType permissions are enforced automatically? - In places where a bypass is unavoidable (e.g., anonymous cart), would you adopt the new Signed Guest Session pattern instead of
ignore_permissions?
- Would you keep using
-
API Design
- Any plan to expose core objects—Product, Cart, Order—via the auto‑generated OpenAPI / GraphQL layer and reserve RPCs only for composite actions?
- How will you handle versioning and backward compatibility for clients that currently depend on the HTML‑returning RPCs?
-
Frontend Strategy
- Would you drop server‑side Jinja snippets in favour of a JSON API plus a client‑side component library (Frappe UI / Tailwind)?
- Thoughts on enabling headless mode so that Webshop can be the e‑commerce back‑end while merchants pick their own storefront tech?
-
Security Hardening
- Are you planning to audit the existing allow‑guest endpoints and add rate‑limiting / CSRF protection?
- Will the new stack rely on DocType Role Permissions Manager exclusively for CRUD and restrict special RPCs to authenticated users?
-
Data Migration & Compatibility
- For merchants already live on the old Webshop, will you ship a bench command that migrates quotations, website items, and settings to the new schema?
- Any breaking changes in the DocType names or field structures we should prepare for?
-
Modern Frappe Features
- Which of the 2024‑25 additions—Type‑hinted DocTypes, Lazy Migrations, Event Streaming, Dashboards v2—are you keen to leverage?
- Will you adopt Background Jobs v2 for inventory checks and price calculations instead of synchronous RPC calls?
-
Community & Roadmap
- Is there a public milestone for Webshop 2.0? How can external contributors participate (review, docs, QA)?
- Would you consider splitting the project into multiple apps (core API, storefront theme, payment plugins) to keep scopes clear?
Thanks in advance for sharing your thoughts! Your insights will help us (and others) decide whether to wait for a modern Webshop 2.0, contribute to the rewrite, or fork the existing codebase.
Looking forward to hearing from you. 
— A fellow Frappe developer