unknown

When a business rule must be enforced on both the backend and frontend, duplicating logic leads to inevitable drift. Three strategies are explored: sharing code (risky across separate deployments or different languages), shipping the decision (backend returns computed allowed actions like `allowedActions: ['CANCEL']` so the frontend renders state rather than re-deriving it), and shipping the policy (serializing rules via tools like CASL or JSON Schema so only a stable evaluator is shared, not the volatile business logic). The recommendation is to always share something — preferably as data — rather than letting the same invariant live in two places.

Ship the policy, not the code

SeyoungCho

As with every design decision, there are always tradeoffs to be made. A single source of truth is always preferable to duplication as long as it does not lead to additional pain points. For instance, having a single source of truth may result in additional complexity during a build phase or introducing a shared component that would not exist if the duplication existed. Every design decision needs to consider the pros and cons rather than being dogmatic about golden rules.

I’ve seen shared libraries solve duplication and accidentally create dependency headaches. sometimes agreeing on the rule is more valuable than agreeing on the code.

If the same rule exists in both frontend and backend, they’ll eventually get out of sync. It’s easier if the backend decides and the frontend just follows.

How about change tech stack and approach for once and do not duplicate logic, since everything must sit in the backend anyway?

Shipping policy data is powerful, but the backend must still enforce the rule because a cached or modified client policy is only a UX hint. I would version the policy schema and include the decision inputs or a decision token so client-visible actions can be correlated with the server’s final authorization. Otherwise a deployment race can produce the same drift problem in a serialized form.