jeffersongoncalves/flysystem-google-drive
A Flysystem adapter for Google Drive, letting you read, write, list, and delete files on Google Drive through Laravel's familiar Storage API. Drop it in as a disk driver to sync uploads and backups without changing your existing filesystem code.
Architecture fit. The package is a League Flysystem v3 adapter with a Laravel service-provider wrapper, which means it plugs into the Storage facade and the filesystems.php disk registry rather than introducing a parallel abstraction. Laravel 9+ ships Flysystem 3, so this is the native extension point — good fit for any code already written against Storage::disk(...).
Integration feasibility. Low effort on the happy path: composer require, one disk entry, credentials via env, then a smoke test of put/get/list/delete. Realistic to a working dev-environment proof in 1–3 days. The unknown is credential shape (service-account JSON vs. OAuth refresh token) and whether Shared Drives are supported — those drive the rest of the estimate.
Technical risk. Version 1.0.0 is a first release from an unproven, likely single-maintainer project. The headline value is a set of correctness fixes against an unmaintained alternative — isReachable() returning false instead of throwing on a missing folder, delete() surfacing real API errors, path-cache invalidation after move/rename, and query-string escaping. Those are meaningful (the last is a security fix; the second prevents silent data loss), but they are also a signal that this layer sits thin over a nontrivial API with real semantic mismatches: Drive addresses files by ID, permits duplicate names, is case-insensitive by default, and has no atomic rename.
Key questions.
url() and temporaryUrl() return, given Drive has no presigned-URL equivalent?Stack fit. Laravel 9/10/11 on PHP 8.x with Flysystem 3. Verify Composer constraints against the app's pinned framework version before committing.
Migration path. If the app already uses the Storage facade, this is a disk swap with no call-site changes. If migrating off the unmaintained alternative, expect behavioral deltas rather than API deltas: delete() now throws on real errors, and isReachable() now returns false rather than throwing. Audit all try/catch blocks and existence checks around those two calls — code that was silently tolerating failures will now surface them.
Compatibility caveats. No presigned/temporary URLs; visibility is Drive-permission-based, not ACL-flag-based; no atomic rename; duplicate filenames are legal in Drive but not in S3/local semantics. Backfill existing objects with a one-off copy (rclone or a console command) — the path cache warms lazily on first access, so there is no separate indexing step, but also no pre-flight validation of existing keys.
Sequencing.
Maintenance. Pin an exact version and watch upstream commit cadence and issue response. The codebase is small, so a fork-and-own contingency is credible — but budget for it. Re-evaluate at every Laravel major and any Flysystem major bump.
Support. The load here is Google Workspace administration, not PHP: OAuth consent and scope changes, service-account key rotation, quota incidents, and sharing/permission troubleshooting. Assign a named owner for the Google Cloud project. Note that files created by a service account are owned by that account unless written into a Shared Drive — a known cause of "missing files" tickets after key or account changes.
Scaling. Bound by Drive API quotas (per-user and per-project), per-file write limits, and listing latency. The folder-as-file model makes deep hierarchies expensive to traverse. This is appropriate for documents, exports, and moderate-volume user uploads; it is not appropriate for high-IO, many-small-file, or queue-backed workloads. Do not put session or cache storage here.
Failure modes. 401 on expired/revoked tokens; 403 on rate limits or insufficient scope; 404 from a stale path cache after out-of-band moves in the Drive UI; 409/ambiguous resolution on duplicate names; orphaned files from interrupted resumable uploads. Add retry-with-backoff on 429/5xx and a periodic reconciliation job that diffs Drive contents against expected keys. Because delete() now propagates real errors, user-facing delete flows need explicit error handling where they previously passed silently.
Ramp-up. Roughly half a day for a Laravel developer. On-call needs a runbook covering credential rotation, quota incidents, orphan cleanup, and the ownership model for service-account-created files.
How can I help you explore Laravel packages today?