Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Yahoo Finance Laravel Package

dejwcake/yahoo-finance

dejwcake/yahoo-finance is a Laravel/PHP package for integrating Yahoo Finance market data into your applications. Use it to retrieve stock quotes and financial information through a simple API, making it easier to add market data features to your projects.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. The package is a conventional Laravel package: a service provider merges and publishes config/yahoo-finance.php, reads YAHOO_FINANCE_API_KEY, and binds YahooFinanceClient as a singleton over a Guzzle/PSR-18 HTTP client carrying the X-API-KEY header. That fits Laravel’s container and configuration model cleanly and requires no database, queue, or infrastructure changes. Internally it separates a generic ApiClient layer from Yahoo-specific endpoints and response factories, which is a sensible seam. For a TPM, the important architectural point is that the public surface is small — primarily getStockQuote() and getStockHistory() plus typed request/response models and enums. That makes it easy to wrap behind an internal interface so the business logic does not depend directly on this vendor or package.

Integration feasibility. High for a Laravel 10–12 application on PHP 8.2+. Adoption is a Composer dependency, a published config file, an environment variable, and constructor injection of the client. There are no migrations, no schema ownership, and no runtime services to operate. The package is also described as framework-agnostic for standalone PHP, though the Laravel path is the primary one. A competent Laravel engineer can produce a working spike in under a day; production hardening around caching, retries, observability, and vendor terms is the larger effort.

Technical risk. The dominant risk is not the PHP code; it is the external dependency on yfapi.net. The package is a thin client for a third-party commercial API. Before committing, a TPM needs clarity on account cost, quota, rate limits, SLA, data redistribution rights, and terms of use. Package-level risks are also material: zero GitHub stars, a single-maintainer profile, a young 2.x line, and GPL-3.0 licensing. GPL-3.0 is a copyleft license and warrants legal review before use in proprietary or distributed software; internal SaaS use may be acceptable in many organizations, but that is a counsel question, not an engineering assumption. The AGENTS.md file indicates AI-assisted contribution and a documented review/QA process, which is a positive signal for code quality but does not replace community validation or commercial support. Reliability features such as retries, circuit breaking, caching, and rate-limit handling are not evident in the package surface and should be assumed to be the application’s responsibility. The CI matrix covers PHP 8.2–8.5 and the code targets Laravel 10–12, but runtime support should be confirmed against composer.json rather than inferred from CI alone.

Key questions.

  • What are the commercial terms, rate limits, SLA, and data redistribution rights for yfapi.net?
  • Is GPL-3.0 acceptable for the intended deployment and distribution model?
  • Is this package affiliated with or endorsed by Yahoo Finance or yfapi.net, or is it an independent wrapper?
  • What is the maintainer bus factor, expected release cadence, and policy for external PRs and security disclosures?
  • Does the package provide any retry, caching, or rate-limit behavior, or is that entirely the consumer’s responsibility?
  • What were the breaking changes in 2.0.0, and what is the support window for 1.x?
  • What is measured test coverage, and are recorded API fixtures kept current with upstream schema changes?
  • What is the declared Laravel and PHP support range for 2.x, and when is Laravel 13 expected?

Integration Approach

Stack fit. Best fit is a Laravel 10–12 application on PHP 8.2–8.4 with Composer, Guzzle/PSR-18, and standard Laravel configuration and secret management. Standalone PHP is supported in principle, but the package’s configuration and singleton binding are Laravel-oriented. It assumes outbound HTTPS access to the Yahoo Finance API endpoint and a provisioned API key. It does not assume a particular database, queue driver, or hosting model.

Migration path. For greenfield work, install the package, publish the config, set YAHOO_FINANCE_API_KEY, and call the client through an internal adapter. For an existing bespoke Yahoo or market-data client, wrap the package behind the same internal interface and migrate call sites incrementally; do not let package models leak into domain code. From 1.x, treat the 2.0.0 major as a separate migration with its own discovery and test pass. For a future vendor swap, the adapter should expose only the business concepts needed — quote, historical range, interval — and translate package enums and response models at the boundary.

Compatibility. The package targets PHP ^8.2 and Laravel 10–12 according to its contributor documentation, with CI across PHP 8.2–8.5. PHPUnit 11/12 is development-only and does not constrain consumers. The GPL-3.0 license must be checked against the application’s license and distribution model. The API key is passed as an X-API-KEY header to a third party, so secret handling and egress logging need standard review. Confirm the exact illuminate/* constraints in composer.json before assuming Laravel 13 readiness.

Sequencing.

  1. Legal and procurement review of GPL-3.0 and the yfapi.net terms, cost, and data rights.
  2. Provision a non-production API key and validate quota and rate limits.
  3. Build a time-boxed spike behind an internal MarketDataProvider interface.
  4. Add application-owned caching, timeout, retry, and observability around the adapter.
  5. Run a limited pilot with explicit exit criteria — API reliability, data accuracy, latency, and cost per call.
  6. Decide whether to standardize, fork, or replace with a first-party or more commercially supported client.

Operational Impact

Maintenance. Ongoing code maintenance is low: no new infrastructure, no schema, and a small public API. The real maintenance burden is dependency and vendor management — tracking package releases, monitoring yfapi.net API changes, rotating API keys, and keeping the adapter aligned with upstream response schemas. If the package is used in multiple services, centralize the adapter in an internal package to avoid duplicated hardening.

Support. There is no evidence of commercial support. Zero stars and a single-maintainer profile mean the organization should be prepared to fork or replace the package if it is abandoned. GPL-3.0 permits forking, which is a meaningful contingency, but a fork creates internal ownership cost. The documented QA process — PHPCS, PHPStan, PHPMD, PHPUnit, protected main, and CI across supported PHP versions — is a positive supplier-health signal and reduces, though does not eliminate, the risk of silent regressions.

Scaling. The package makes synchronous HTTP calls per request. Application scale is therefore bounded by the upstream API’s quota and latency, not by Laravel or PHP capacity. For dashboards, quote pages, or batch analytics, the application must add caching, request coalescing, and possibly asynchronous refresh. The package does not appear to provide batching or bulk quote retrieval, so high-cardinality use cases should be modeled carefully. Timeout is configurable, but retry and circuit-breaker behavior should be implemented by the consumer.

Failure modes. Watch for upstream API outage or degradation, quota exhaustion and HTTP 429 responses, API key revocation or billing lapse, silent JSON schema drift breaking response factories, package abandonment, and supply-chain risk from transitive dependencies. The GPL-3.0 license is a compliance failure mode if distribution was not anticipated. There is also a product risk that market data is delayed, incomplete, or legally restricted for the intended use. Mitigations are straightforward: pin versions, isolate behind an adapter, cache aggressively, monitor error rates and upstream latency, define a fallback data source, and keep a documented exit plan.

Ramp-up. Developer ramp-up is low because the API is small and expressive, with typed models and enums. The real learning curve is domain and vendor knowledge: interval and range semantics, market-hours behavior, symbol conventions, and yfapi.net quota and licensing rules. A TPM should treat this package as an accelerator for a pilot or internal tool, not as a strategic platform dependency, until the license, vendor contract, and support posture are resolved. The recommended posture is conditional adoption: wrap it, pin it, measure it, and retain a credible replace path.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox