Google Sheets Bundle Laravel Package

Product Decisions This Supports

• Buy-vs-build on "Sheets as a lightweight backend." This package answers a recurring PM question: do we pay engineering to build an admin surface, or do we let ops/marketing edit a spreadsheet and read it at runtime? It bundles that capability (auth, service wrapper) into a drop-in Symfony service, so the decision becomes "a composer require" instead of "a two-week internal tool." As of v1.3.0 the package also ships its own SheetsServiceInterface, so the "we can swap it later" promise is now a one-line type hint rather than a refactor we owe ourselves.
• Feature scoping for content and configuration surfaces. Good fit for low-velocity, human-curated data: pricing tables, FAQ copy, locale strings, partner logos, promo banners, internal reference tables. If a feature's data changes weekly by a non-engineer, this is a cheaper path than a CMS or an admin CRUD build.
• Roadmap sequencing for internal tooling. Lets you defer real admin UI work in a v1/MVP and revisit once usage patterns are known — a de-risking move, not a permanent architecture commitment. The new SheetsWriteEvent (PSR-14, dispatched after append/update/clear/addSheet/deleteSheet) also gives us a supported hook for cache invalidation and audit logging without forking or wrapping the write path — that removes one of the main recurring engineering arguments against the shortcut.
• Stakeholder-facing reporting and exports. Read/write access to Sheets is often what unblocks finance/ops dashboards without standing up a warehouse pipeline; useful for prototypes and pilot programs where the spreadsheet is the system of record.
• Prototype and discovery work. For validating demand before investing in a proper data model, this removes the "we need a backend first" blocker from a discovery sprint. The in-memory fake (now shape-checking on append(), matching production) means we can build and demo the flow in CI without live credentials.
• Explicit non-decision: it does not justify replacing a real database. Position it as a deliberate tactical shortcut with a documented exit path, not as an architectural standard. The v1.3.0 interface makes the exit path cheaper — it does not make the data model any less of a spreadsheet.

When to Consider This Package

Adopt only when all of these hold:

• The consuming application is Symfony, not Laravel. This is a Symfony bundle wrapping revolution/laravel-google-sheets — a Laravel package — which means non-trivial transitive baggage in a Symfony app and no benefit at all in a Laravel app, where you would use the underlying package (or google/apiclient directly) instead.
• The data is low-write, low-concurrency, and non-critical — no transactional guarantees, no per-request write bursts, no data whose loss breaks the product. SheetsWriteEvent gives you an after-the-fact notification; it is not a transaction boundary, so it does not change this criterion.
• You can tolerate Google API quotas, latency, and OAuth/service-account credential management as an ongoing operational responsibility.
• You can keep reads off the user-facing hot path, or put caching in front of them. Note that SheetsWriteEvent fires from a single application instance — with multiple app servers or out-of-band spreadsheet edits, it is not a distributed invalidation mechanism. Budget a TTL or a shared cache store.
• You accept a hard dependency on a single maintainer with 0 stars, 0 dependents, and no downstream validation. Overall score (~12.9) is low; v1.3.0 is a real quality release, but activity from one maintainer is not the same as adoption. Treat this as unproven code, not infrastructure.
• You type-hint against SheetsServiceInterface, not the concrete SheetsService. The interface now covers read/write/discovery/metadata and is what SheetsRegistry::service() returns. Be aware the escape hatches (client(), driveService()) intentionally remain on the concrete class — if your code needs those, the swap-out story weakens.

Look elsewhere when:

• You're on Laravel. Use revolution/laravel-google-sheets directly, or google/apiclient if you want full control. Adding a Symfony wrapper to a Laravel app is inverted and unjustifiable.
• Reads are on the critical path of user-facing latency (every page load hitting the Sheets API is a product-quality risk, not a tooling choice).
• You need write-heavy or multi-user concurrent editing — Sheets has no real locking or transactional semantics.
• You need a maintained, supported dependency. Sparse adoption plus a single maintainer is a bus-factor-1 risk; if your org requires vendor/SLA coverage, this fails that bar.
• You want a first-class Google Sheets integration as a product feature (e.g. customer-facing sync) — build directly on the official SDK so you own the auth, retry, and quota logic rather than inheriting it.
• Compliance matters. Sheets is a third-party data processor; PII, regulated data, or anything in a data-processing agreement should not land here.
• You need observable, debuggable behaviour out of the box. The profiler tracer is still maturing (v1.3.0 fixed dropped traces on early break, missing findSheetNameById traces, and truncated call-site capture); good enough for dev, don't sell it as production observability.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed integration that lets our Symfony application read and write Google Sheets directly, so business teams can edit content and reference data in a tool they already use instead of waiting on engineering for an admin panel. It's a speed-and-cost play for low-risk internal data: it compresses weeks of internal tooling into days and lets us validate features before committing to a real CMS or database. The latest release adds the two things we'd otherwise have had to build ourselves — a stable interface to code against, so migrating off is contained, and write notifications, so cache and audit behaviour is handled without custom plumbing. The trade-off is unchanged and deliberate: it's maintained by a single developer with essentially no external adoption, so it's appropriate for internal, non-critical, low-traffic data only, and we should budget a migration path rather than treat it as permanent infrastructure.

To engineering (one paragraph): gulaandrij/google-sheets-bundle v1.3.0 is a Symfony bundle that wraps revolution/laravel-google-sheets. The layering caveat still stands: on Laravel, use the underlying package and skip this. On Symfony, v1.3.0 materially improves the integration story — SheetsServiceInterface is implemented by all four service variants and autowired as SheetsServiceInterface $<name> alongside the existing concrete aliases, and SheetsRegistry::service() now returns the interface, so inject the interface and keep the concrete type out of feature code. SheetsWriteEvent (PSR-14) fires after successful writes with operation, spreadsheetId, sheetName, range, rowCount — use #[AsEventListener] for cache invalidation and audit logging; reads deliberately don't dispatch, and the event dispatcher is optional (nullOnInvalid()) so apps without symfony/event-dispatcher still boot. The in-memory fake now enforces the same homogeneous-row shape check as production (MixedRowShapeException), so tests no longer drift from real behaviour. Caveats: client() and driveService() remain on the concrete class only, so anything needing raw SDK access is not covered by the abstraction; the event is per-instance, not a cross-node invalidation bus; and adoption signals are still thin (0 stars, 0 dependents, single maintainer). Recommendation: acceptable for internal tooling and prototypes, type-hint the interface, add caching in front of reads, and keep a documented swap-out plan.