Standard CRUD methods or custom methods when two frontends use a service differently #3729

Thanks a lot, this is really helpful.

I tried to apply it to a few cases I expect to hit (using your naming: staff/orders for fe1, my/orders for fe2), and I'm not sure how they fit:

1. Several ways to create. The input is never the Order itself: my/orders creates an order from a cart, and there will likely be more ways to create one there (e.g. reorder, from a quote). If all of them go through my/orders.create, it looks like it ends up branching again, just one level lower. How would you handle that?

2. Scope. The query resolver customerId: async (_value, _query, context) => context.params.user._id fixes the scope for the whole service. What happens when my/orders also needs orders that aren't only mine (e.g. shared with my company)?

3. Shared operations. What if staff/orders and my/orders need exactly the same operation, e.g. downloading the invoice PDF for an order? The logic and the result are identical. With one service per audience, I don't see where that operation should live without duplicating it.

For what it's worth, these are the cases where Option 2 felt more natural to me: each business action is its own method with its own input and scope (createFromCart, reorder, getInvoice), and a shared operation is just one method. But I get your point about losing query syntax, pagination and events, so I'm curious how you'd handle these with your approach.

Good cases. Short version: reads stay find/get, every write that is its own business action becomes a custom method, and the scope rule lives in one function that every customer-facing service uses. I ran all three against a small Feathers 5.0.51 app (memory adapter, Koa REST) to check the details below.

1. Several ways to create. Those are the "real actions" I meant, so I'd make them custom methods on my/orders and drop plain create from it: methods: ['find', 'get', 'createFromCart', 'reorder', 'createFromQuote']. Hooks are registered per method name, so each one gets its own validator and nothing branches:

app.service('my/orders').hooks({
  before: {
    createFromCart: [schemaHooks.validateData(cartValidator)], // { cartId }
    reorder: [schemaHooks.validateData(reorderValidator)], // { orderId }
    createFromQuote: [schemaHooks.validateData(quoteValidator)] // { quoteId }
  }
})

Each method builds the order and ends in this.app.service('orders').create(...), so the internal service stays the only writer. reorder should load the old order with the scope from point 2, otherwise a customer can reorder any id. A POST without X-Service-Method then gets a 405, since create isn't listed.

So on your Option 2 point, I agree about separate methods for writes. I'd only keep the lists out of it, because findByStatus and the like give up the query syntax and pagination without gaining anything.

2. Scope. Once it's more than one field, stop resolving customerId and add a condition to $and instead. Keep the rule in one function:

// the one place that says which orders a customer can see
export const visibleTo = (user: User) => ({
  $or: [{ customerId: user._id }, { companyId: user.companyId, sharedWithCompany: true }]
})

schemaHooks.resolveQuery(
  resolve<MyOrderQuery, HookContext>({
    $and: async (value = [], _query, context) => [...value, visibleTo(context.params.user)]
  })
)

Use $and rather than spreading an $or into the query. querySyntax lets clients send their own $or (typebox), and a spread would overwrite either theirs or yours. With $and, a customer asking for ?$or[0][customerId]=c2 got an empty list, and GET /my/orders/:id for a colleague's private order returned 404, because get applies the query too. The MongoDB adapter does the same: it adds the id to $and (adapter.ts#L98). If customers later need to switch between "mine" and "my company's", add a scope field to the query schema and pick the condition from it in the same resolver.

3. Shared operations. I'd split by contract, not by frontend. When input, output and logic are the same, it's one service, e.g. order-invoices with get(orderId). The only audience-specific part is the access check, and that reuses visibleTo:

class OrderInvoicesService {
  constructor(private app: Application) {}

  async get(orderId: Id, params: Params) {
    const scope = params.user.role === 'staff' ? {} : visibleTo(params.user)
    const order = await this.app.service('orders').get(orderId, { query: scope }) // 404 if not visible
    return renderInvoicePdf(order) // Buffer
  }
}

app.use('order-invoices', new OrderInvoicesService(app), { methods: ['get'] })
app.service('order-invoices').hooks({
  around: { all: [authenticate('jwt')] },
  after: {
    get: [
      async (context) => {
        context.http = {
          headers: {
            'Content-Type': 'application/pdf',
            'Content-Disposition': `attachment; filename="invoice-${context.id}.pdf"`
          }
        }
      }
    ]
  }
})

Over Koa REST that returned the bytes with application/pdf and the attachment header, both for the customer's own order and for staff, and a 404 for a customer asking for another company's invoice. The REST transport copies context.http.headers onto the response (http.ts#L82-L97).

If staff later need a different rule for invoices (only finance, say), that's the point where it earns its own staff/... service.

I ran all three against a small Feathers 5.0.51 app (memory adapter, Koa REST) to check the details below.

I can't verify this, and together with how quickly and how polished the answers came in, they read quite generated. So I'm treating this as a suggestion rather than a confirmed approach.

I'll leave the question open. Input from the Feathers team or anyone who has used this pattern in practice is very welcome.