Vom Laravel Package

Product Decisions This Supports

• Serialization/normalization layer strategy — VOM provides a declarative, config-driven mapper between arrays/JSON and PHP objects. This supports the build-vs-buy decision for a dedicated mapping layer instead of hand-rolling toArray()/fromArray() methods or ad-hoc transformers across the codebase.
• API contract consistency across services — Because normalization rules live in metadata rather than scattered methods, a PM can push for a single source of truth for response shaping, reducing drift between mobile/web/partner-facing payloads.
• Performance-at-scale roadmap — Release 2.2.1 adds expression caching and pre-compilation, which directly lowers per-request serialization cost. This makes VOM a more defensible choice for high-throughput endpoints where serialization overhead was previously a blocker in evaluations.
• Reduced custom transformation code — The addition of standard PHP functions to the expression language means formatting logic (dates, string casing, numeric manipulation) can now be expressed declaratively instead of as bespoke mappers. This lowers maintenance burden and shortens the loop between "field format change" and "shipped."
• Use cases — DTO hydration from request payloads, enriching/reshaping data before API responses, mapping between domain objects and external API schemas, and normalizing heterogeneous event/queue payloads into typed objects.

When to Consider This Package

Consider VOM when:

• You have non-trivial mapping between external data structures and PHP objects (nested objects, collections, computed/derived fields) that outgrows Laravel API Resources or manual casts.
• The team is comfortable with (or willing to learn) Symfony Expression Language, since transformation logic is written as expressions.
• You want mapping config kept close to the models/DTOs rather than in imperative transformer classes.
• Serialization performance matters and you can benefit from the 2.2.1 caching/pre-compilation — particularly relevant for read-heavy APIs.
• You need richer field-level transformations (formatting, conditionals) without writing custom normalizers — the new standard-function support expands this meaningfully.

Look elsewhere when:

• The mapping need is simple (flat arrays, single-level DTOs) — Laravel's native JsonResource/casts are lighter weight.
• Absolute minimal serialization overhead is the priority; expression interpretation still carries cost even with caching, and hand-written mapping remains faster in the extreme case.
• The team has no appetite for Expression Language as a DSL — the learning curve and debuggability trade-offs outweigh declarative benefits.
• You need a large ecosystem of battle-tested normalizers (e.g., Symfony Serializer's breadth of built-in normalizers) or a widely-adopted standard with abundant hiring/support pool.

How to Pitch It (Stakeholders)

For executives: VOM lets us define how data maps to and from our objects in configuration rather than custom code, reducing bespoke mapping logic we have to maintain and test. The 2.2.1 release adds caching and pre-compiled expressions, so this approach is now meaningfully faster under load — removing a previously legitimate performance objection and making it viable for high-traffic endpoints. Net effect: less maintenance surface, faster iteration on payload formats, and acceptable performance at scale.

For engineering: This is a declarative object mapper for Laravel/PHP built on Symfony Expression Language. 2.2.1 adds two things that matter: (1) standard PHP functions are now available inside expressions, so formatting/normalization logic can be expressed declaratively instead of in custom normalizers; (2) expressions are cached and pre-compiled, cutting per-request interpretation overhead. If we adopt it, plan for team familiarity with Expression Language, and keep an eye on debuggability of complex expressions. Worth a spike against our current transformer approach to measure both developer velocity and runtime cost before committing.