Weave Code
Dystore Api Laravel Package
dystcz/dystore-api
JSON:API layer for the Dystore headless commerce stack on Laravel. Exposes products, carts, orders, customers, and checkout as JSON:API endpoints built on Lunar, letting any storefront, SPA, or mobile app run off a single Laravel backend.
[READ ONLY] API layer for Lunar headless e-commerce package based on JSON:API
Frequently asked questions about Dystore Api
- What is dystcz/dystore-api and what does it actually do?
- It is a presentation layer for Laravel headless commerce that sits on top of Lunar and exposes your catalog and order domain through a JSON:API contract. Lunar owns the entities, pricing, and persistence, while Dystore owns routing, serialization, sparse fieldsets, includes, filtering, and pagination semantics. It is not a standalone e-commerce package; it converts an in-process domain package into a consumable HTTP API so a SPA, mobile app, or any JSON:API client can run off one Laravel backend.
- Can I use dystcz/dystore-api without Lunar?
- No. The package presumes the Lunar data model and its version line, so adopting Dystore means adopting Lunar, its migrations, and its release cadence in the same decision. The realistic evaluation is Lunar plus a JSON:API layer as a bundle, not Dystore in isolation. If you are not already committed to Lunar as your commerce core, this is not an entry point for you.
- How do I install and configure dystcz/dystore-api in a Laravel app?
- Installation is a standard Composer install into a Laravel application, followed by route registration and JSON:API configuration covering the server definition, resource schemas, and authorization hooks. The friction is concentrated in three areas: the JSON:API spec surface itself, authentication wiring, and the write path. Plan for the configuration step to be more involved than a typical package because resource schemas map directly to Lunar entities.
- Which Laravel and Lunar versions are supported?
- The package targets Laravel 10/11-era applications using Composer, MySQL or Postgres, Redis, and a queue worker. Version compatibility with Lunar, and transitively with Laravel, is the dominant technical risk, because Lunar's domain model is still moving and a major bump can strand this layer. Verify the supported Lunar majors and the demonstrated upgrade latency across the last two Lunar majors directly against the repository before committing.
- Is dystcz/dystore-api read-only, and how do I handle cart and checkout mutations?
- The repository description marks the package as read-only, which, if it means GET-only endpoints, pushes cart, checkout, payment, and customer mutations entirely outside this package and into bespoke controllers you write and maintain. This is the single largest scope question and should be resolved before you commit to the integration. Ask the maintainers what the sanctioned write path is for cart, checkout, and customer mutations.
- How does authentication and authorization work with this JSON:API layer?
- You will be wiring Sanctum or Passport and per-resource authorization policies yourself; the package provides the JSON:API surface, not a ready-made auth story. Multi-store and multi-currency scoping and localization may be in-package or left to the host app, so confirm that early. Treat authorization design as part of your own application work, not something the package hands you.
- What are the performance risks with JSON:API includes and filtering?
- Include-driven eager loading is powerful and easy for clients to abuse, and unbounded includes against a large catalog are a predictable performance incident. The read-heavy nature of the API means N+1 exposure grows as clients request deeper relationship trees. Mitigate with allowed-include whitelists, request limits, caching, and monitoring rather than assuming the package enforces sane defaults.
- Is dystcz/dystore-api actively maintained and safe for production?
- Community signals are small, with roughly 42 stars and a low composite score, which suggests you should expect to be a first-line debugger rather than a support-ticket filer. Check the actual tag history and commit activity yourself, and confirm whether the project is maintained by an individual or an organization with a support commitment and whether a paid tier exists. Before production, review observed test coverage and CI signal on the default branch, and ask for reference deployments at meaningful catalog scale.
- Does the JSON:API contract add complexity my frontend team has to learn?
- Yes. Clients must handle the application/vnd.api+json media type, compound documents, and the include, fields, and filter query grammar along with relationship linkage. JSON:API is excellent for generic clients but poor for teams without prior spec experience, and the retraining cost is real and often underestimated. Budget for that learning curve on the storefront side, not just the Laravel side.
- How does it compare to writing my own Lunar API controllers, and can I fork it?
- Hand-rolling controllers, resources, and query parsing around Lunar is exactly what this package saves you, so the comparison is build time versus upstream coupling risk. The MIT license means forking is the realistic mitigation if maintenance slows or a Lunar major bump strands the layer. If your roadmap includes a server-rendered Blade storefront, this package adds a contract you will not use plus a dependency you still have to patch.
Weaver
How can I help you explore Laravel packages today?