madbob/easyrdf-on-guzzle
Provides a Guzzle-backed HTTP client adapter for EasyRdf, acting as a drop-in replacement for its default client so you can fetch and parse RDF resources through Guzzle's request handling, middleware, authentication, proxies, and timeout configuration while keeping EasyRdf's familiar API.
Architecture fit. EasyRdf resolves HTTP through an injectable client abstraction (EasyRdf\Http\ClientInterface in 1.x, the older EasyRdf_Http_Client in 0.9). By default that drags in a Laminas/Zend HTTP client — a dependency Laravel applications otherwise never need. This package substitutes Guzzle, which is already present in every Laravel stack (Laravel's Http facade is a Guzzle wrapper). For any service that ingests Turtle/JSON-LD/RDF-XML or queries SPARQL endpoints, the fit is clean: one adapter class, no framework coupling, no service container assumptions. It is a plumbing package, not a capability package — it adds no RDF features, it only removes a redundant HTTP stack.
Integration feasibility. The public surface is almost certainly a single class implementing the EasyRdf client contract plus a request/response translation layer. That is a half-day spike, not a project. The friction is distribution, not code: the repository is GitLab-hosted with no evidence of Packagist publication, so adoption requires a repositories VCS entry or an internal mirror. Autoloading should be PSR-4; verify composer.json declares constraints for both easyrdf/easyrdf and guzzlehttp/guzzle rather than leaving them loose.
Technical risk. High relative to the code's size, and almost entirely supply-chain risk rather than engineering risk. Zero stars, zero dependents, a score of 0, and a single maintainer on a non-GitHub host means no security advisory feed, no downstream canary population, and no community pressure to track Guzzle majors. The specific compatibility questions are: EasyRdf 1.x (EasyRdf\ namespace) vs 0.9 (EasyRdf_), Guzzle 6 vs 7 handler-stack semantics, and whether PSR-7 responses are converted back into the mutable response object EasyRdf's parsers expect.
Key questions.
Http\ClientInterface or the legacy class?Content-Type, Content-Location, and final-URL-after-redirect? EasyRdf selects its parser from the response content type — a dropped header causes silent parse failures, not exceptions.Stack fit. Laravel 10–12, PHP 8.1+, Guzzle 7. The strongest argument for this package is not the adapter itself but the ability to hand EasyRdf a pre-configured Guzzle client — one that already carries the application's retry middleware, structured logging, OpenTelemetry tracing, proxy and TLS settings, and circuit breaker. That gives RDF traffic the same operational envelope as every other outbound call in the app, which is difficult to achieve with the Zend client.
Migration path. If a service already uses EasyRdf with the default Laminas client, the swap is a bootstrap-time setDefaultHttpClient() call, ideally behind a config flag. Do not let EasyRdf\Http be configured ad hoc inside domain code — wrap it in one internal RdfClientFactory so the adapter is replaceable in a single file. Mirror the repository internally (Satis, private Composer repo, or a forked VCS entry) and commit the lock file; never let production builds resolve directly against gitlab.com.
Compatibility. Confirm the package's declared constraints before anything else. Test against the exact EasyRdf minor we run, with static analysis (PHPStan/Larastan) and a contract test suite that exercises: 200 with body, 404, 500, a 302 chain, a chunked/gzip response, and a response with no Content-Type. Those five cases are where adapters of this shape break.
Sequencing.
Build-vs-adopt. Given the score of 0 and zero dependents, treat the repository as reference implementation, not a dependency. Reimplementing the adapter in-house is on the order of 100–200 lines and eliminates the fork, the mirror, and the supply-chain question entirely. That is the recommended path unless the spike shows the package is materially more than a thin translation layer.
Maintenance. Effectively unmaintained. Plan for zero upstream responsiveness: no Guzzle 8 support, no PHP 9 fixes, no CVE patches. The realistic operating model is "vendored code with an internal owner," and that ownership cost should be booked explicitly — a few hours per quarter plus a re-review on every Guzzle or EasyRdf major.
Support. No vendor, no SLA, no issue-tracker activity to rely on. Escalation is entirely internal. Ensure the source is captured by software-composition analysis; VCS-installed packages routinely fall outside default SCA coverage, which is the single most likely governance gap here.
Scaling. The adapter is stateless, so throughput is governed by the Guzzle handler stack — curl multi, connection reuse, and pool sizing — not by this package. The real scaling constraint is downstream: EasyRdf builds an in-memory graph, so large responses are CPU- and memory-bound and the HTTP layer merely hides it. Enforce response size ceilings and streaming where the endpoint supports it. Absent explicit timeouts (connect, read, total), a slow SPARQL endpoint will pin PHP-FPM workers; set them in the injected Guzzle client, not in the adapter.
Failure modes.
Content-Type — the highest-probability defect and the hardest to detect, because EasyRdf may fall back to a guess or return an empty graph rather than throwing.RequestException in queue workers.Ramp-up. Low for the mechanical integration (an engineer familiar with Laravel and Composer is productive in under a day), but debugging failures requires RDF domain literacy — content negotiation, graph semantics, and parser selection are not skills the average Laravel developer carries. Budget a day for integration and roughly a day for the contract-test suite and failure-mode validation, and document the adapter's content-type and redirect contract in the repo so the next on-call engineer does not rediscover it at 2 a.m.
How can I help you explore Laravel packages today?