- What is google/cloud-core used for in Laravel applications?
- google/cloud-core is the shared foundation behind the official Google Cloud PHP client libraries. In a Laravel app it provides common authentication, HTTP transport, retry and backoff handling, pagination, and serialization used by packages such as google/cloud-storage, google/cloud-bigquery, and google/cloud-firestore. You normally benefit from it indirectly rather than calling it from your own controllers or jobs.
- Do I need to install google/cloud-core directly in Laravel?
- Usually no. It is installed automatically as a dependency when you require a Google Cloud PHP service package like google/cloud-storage. You can run composer require google/cloud-core, but the package explicitly says it is not intended for direct use. Add the specific google/cloud-* package for the GCP service you need.
- How does google/cloud-core handle authentication in a Laravel app?
- It supports Application Default Credentials and service account credentials for Google Cloud PHP libraries. In Laravel, the common pattern is to set GOOGLE_APPLICATION_CREDENTIALS in .env or the server environment and let ADC resolve credentials. You generally do not need a Laravel service provider or facade for core itself; the dependent Google Cloud package uses the credential configuration.
- Does google/cloud-core support retries for Laravel queue jobs calling Google Cloud?
- Yes, it provides configurable retry and backoff logic through RetryOptions for Google Cloud PHP API calls. This can complement Laravel queue retries, but you should decide whether Google client retries or Laravel job retries own a given failure path. For Storage writes, v1.74.0 added idempotency tokens that make automatic retries safer for operations such as create, update, delete, and compose.
- What changed with idempotency tokens in google/cloud-core v1.74.0?
- v1.74.0 adds Google Cloud Storage idempotency tokens for Storage API operations, improving safe retries for write paths. This is a behavior enrichment in the retry layer rather than a new direct integration surface. Laravel queue jobs that touch GCS can increasingly rely on the client retry behavior instead of custom deduplication, though tests that assert on request headers or wire behavior should be revalidated.
- Which Laravel and PHP versions are supported by google/cloud-core?
- google/cloud-core is a PHP library and does not declare Laravel framework version constraints itself. Compatibility depends on the PHP version required by your Laravel release and by the specific google/cloud-* packages you install. The package is tested up to PHP 8.4. Laravel 10 supports PHP 8.1+, and Laravel 11 requires PHP 8.2+.
- How do I configure retry and backoff settings for Google Cloud PHP in Laravel?
- Retry behavior is configured through the options passed to the specific Google Cloud PHP client, using RetryOptions for retry and backoff settings. Because google/cloud-core is infrastructure, you normally configure this on the service client, such as StorageClient, rather than on core directly. Keep Laravel queue $tries and backoff aligned with the client retry policy so you do not create excessive retry layers. Newer Storage idempotency tokens make automatic retries safer, but you should still avoid retrying non-idempotent custom workflows blindly.
- How can I debug Google Cloud PHP requests from a Laravel app?
- google/cloud-core provides debugging tools documented in the Google Cloud PHP debugging guide. In Laravel you can route the library's debug output into your application logs or a dedicated channel so retried requests and transport details are visible. If you log request metadata, include correlation or token values where appropriate to trace retried operations. Be careful not to log sensitive credentials.
- Is google/cloud-core stable enough for production Laravel deployments?
- Yes, google/cloud-core is GA and commits to no backwards-incompatible changes in minor or patch releases. Major releases of dependent Google Cloud packages can still require updates, so pin versions and test upgrades in staging. Production risk is mostly indirect, such as credential misconfiguration or changed retry behavior, rather than direct API usage from Laravel code.
- What are alternatives to google/cloud-core for Laravel GCP integration?
- For official Google Cloud PHP support, there is no direct replacement because google/cloud-* service packages depend on google/cloud-core. Alternatives would be using Google Cloud REST or gRPC APIs directly with Laravel's HTTP client, or combining lower-level packages such as google/auth with a custom transport layer, but you would lose the shared retry, pagination, and serialization behavior. Third-party Laravel GCP packages may wrap these APIs, but evaluate their maintenance and feature coverage.