Multi-service TypeScript monorepos often suffer from inconsistent resource naming — each team invents its own string interpolation patterns. Inspired by the Google API Design Guide, this post proposes treating resource names as first-class structured data with shared encode/decode utilities. Relative resource names follow a `collection/id` hierarchy, while full resource names prepend `//service.domain/` for cross-service identification. Resource types (`service.domain/TypeName`) handle 'what kind' of resource. A typed `ServiceName` union prevents typos at compile time, and domain-specific constants are constructed via `encodeResourceType` rather than hardcoded. The utilities live in a shared monorepo package, giving every service a single source of truth for resource identity.
Table of contents
The Problem with String InterpolationResource Names as a ConventionFull Resource Names for Cross-Service IdentificationResource Types: What Kind of ResourceTyped Service NamesDomain Constants Instead of Magic StringsOrganizing the Utility in a MonorepoSort: