A service mesh inside the Node.js application boundary.

Application-native means the caller owns the relationship.

With OpenMesh, app.mesh('payments') returns a lazy service handle. The first request creates a managed pool for that relationship; repeated calls reuse it. The pool retains live topology, admission state, circuit history, latency statistics, traffic targeting and transport resources.

This is materially different from sprinkling fetch() calls through handlers. The caller still sees HTTP semantics, but the operational behavior of a downstream relationship is centralized and inspectable.

First choose the subset. Then choose the peer.

OpenMesh 0.5 separates traffic targeting from peer selection. A request can first be narrowed to an eligible subset by metadata, ordered header rules, weighted splits or locality preference. Only then does the peer selector choose an instance inside that subset.

mesh: {
  services: {
    payments: {
      traffic: {
        split: [
          { match: { version: 'v1' }, weight: 90 },
          { match: { version: 'v2' }, weight: 10 }
        ]
      }
    }
  }
}

A stable request key can keep weighted selection sticky. Explicit targets fail closed when no matching peer exists. Retries remain inside the selected traffic subset instead of silently escaping a canary or locality rule.

Backpressure and retries are bounded together.

A distributed call has more states than success and error. It can wait in a queue, consume an in-flight slot, time out before transport starts, fail after headers have been committed, or reach a peer whose circuit is already open.

OpenMesh can bound those states with per-service admission, maxInflight, bounded FIFO queues, one total deadline across queueing and attempts, per-peer circuits and optional adaptive concurrency. Unsafe methods are not retried implicitly; callers can opt in when they have an idempotency key or equivalent guarantee.

Streaming responses have explicit semantics too: once successful non-5xx headers are handed to the caller, a later body failure is surfaced to the consumer and is never replayed against another peer.

Service identity can travel with the same relationship.

OpenMesh supports SPIFFE-style workload identities and mutual TLS. The local runtime validates its certificate before serving traffic; inbound callers can be restricted by service identity, and outbound mesh calls verify that the destination certificate identifies the expected service.

Certificate material can be rotated for new inbound and outbound connections without restarting the application. Issuance, revocation distribution and trust-domain governance are intentionally external.

It is not a drop-in replacement for an infrastructure mesh.

OpenMesh does not provide transparent interception, Kubernetes CNI behavior, certificate authority automation, cross-language proxies or cluster-level policy enforcement. Those are different product boundaries.

The application-native model is strongest when a Node.js team wants explicit service-to-service behavior in code and runtime state, wants to avoid a sidecar hop, and is comfortable keeping infrastructure responsibilities outside the package.

See the application-native mesh deep dive for the exact current contract.

Related OpenMesh guides.