Butler Graphql Laravel Package

Product Decisions This Supports

• API strategy: v13.1.0 adds custom scalar support, making glesys/butler-graphql more viable for Laravel/PHP products that need GraphQL schemas with domain-specific types beyond standard scalars (e.g., money, dates, JSON, identifiers, geo coordinates).
• Build vs. buy: If the roadmap includes a typed GraphQL API, custom scalar support reduces the need to build proprietary serialization/validation plumbing or fork the package to handle non-standard types.
• Feature scoping: Teams can model complex domain values directly in the schema instead of flattening them into strings or JSON, improving API contracts and reducing client-side workarounds.
• Roadmap fit: This is an incremental feature release, not a breaking change. It supports near-term GraphQL feature delivery without forcing a platform migration.
• Use cases: Laravel/PHP backends exposing GraphQL to web/mobile clients, internal APIs with strong typing needs, and products where custom domain types appear frequently across queries and mutations.

When to Consider This Package

Consider adoption when:

• The product is a Laravel/PHP application and the team has decided GraphQL is the right API layer.
• The schema needs custom scalar types—money, timestamps, UUIDs, JSON blobs, geographic coordinates, or domain-specific identifiers—and standard GraphQL scalars are insufficient.
• The team wants to stay within Laravel conventions and avoid building scalar parsing/serialization infrastructure from scratch.
• You can track the package’s release cadence and validate minor upgrades; v13.1.0 appears additive, but changelog review and test coverage are still required.

Look elsewhere when:

• REST or another API style is sufficient; GraphQL adds operational and client complexity without clear product value.
• The team lacks GraphQL expertise or cannot support schema governance, authorization, and performance monitoring.
• You need commercial support, long-term enterprise SLAs, or capabilities not evidenced in the package’s release notes.
• The application is not Laravel/PHP or has strict constraints around package maturity and ecosystem lock-in.

How to Pitch It (Stakeholders)

For executives: This release makes the GraphQL package more capable for real product domains by supporting custom scalar types. That means fewer custom workarounds, faster delivery of typed APIs, and lower long-term maintenance risk for Laravel-based services. It is a minor feature update, so adoption can be evaluated without a major migration.

For engineering: v13.1.0 adds custom scalar support, which removes a common blocker for modeling domain-specific values in GraphQL schemas. Teams can implement scalars for money, dates, JSON, IDs, or other types instead of encoding them as strings or ad hoc structures. The release appears additive; validate against existing schema tests and confirm scalar implementations follow GraphQL serialization and validation expectations.