Shopend

In the previous chapters, we designed the shop API as a small, open-source commerce backend. A developer deploys a copy for one merchant, and that merchant’s storefront sends its requests to it. Suppose the project becomes popular. Many merchants use it, and many of them ask for the same thing. They want to build their own storefront, but they do not want to deploy and run the backend themselves.

So we run the backend ourselves. We call it Shopend. A merchant signs up, enters their products, and builds only the storefront. The storefront sends its requests to Shopend. The name is a play on “backend”. The storefront is the part of the shop that shoppers see, and Shopend is the other end. Shopify offers the same arrangement for custom storefronts. We saw this when we first introduced headless commerce.

Shops

Each merchant has one shop on Shopend. A shop has an identifier, such as mugshop for the mug business we have been following. Every product, cart, and order belongs to exactly one shop.

So every request must say which shop it is for. We put the shop’s identifier in the URL path. Here is a request from the mug shop’s storefront for the blue mug:

POST /shops/mugshop/graphql HTTP/1.1
Host: api.shopend.example
Content-Type: application/json

{
  "query": "{
    product(id: 42) {
      name
      priceCents
    }
  }"
}

The query is the one we would have sent to the shop API. Only the URL is different: the host is api.shopend.example, and the path names the shop. Because the path names the shop, the GraphQL schema does not need a shop argument. Every query and mutation we designed earlier works the same way inside one shop.

We could also put the shop in a subdomain, such as mugshop.shopend.example, or in a request header. Any of these works, as long as every request names exactly one shop.