Druid Php Laravel Package

Product Decisions This Supports

• Build vs. buy for the analytics data path. pixelfederation/druid-php is a PHP client for Apache Druid's query API. Its archived status, zero dependents, and lone release in 2017 effectively answer the "buy" side: there is no supported commercial or community PHP client to adopt. The decision this package informs is therefore "do we build a thin in-house client, or do we keep Druid behind a non-PHP query service?"
• Integration tier / architecture. It documents the shape of Druid native queries (timeseries, topN, groupBy, scan) over HTTP and how a PHP application layer would serialize them, sign requests, and parse results. That directly feeds the choice between (a) app-embedded query client, (b) internal analytics microservice, or (c) BI tool (Superset/Metabase) over Druid.
• Use-case feasibility. Useful for evaluating real-time OLAP-backed features in PHP stacks — gaming telemetry, funnel/retention dashboards, live ops KPIs — wherever events land in Druid and the product surface is a PHP web app.
• Licensing and compliance gating. The NOASSERTION license (no recognized SPDX identifier) is a procurement/legal decision input, not a footnote. Any code reuse requires legal clearance; this constrains "copy the patterns" vs. "vendor the source."
• Ecosystem risk signal for warehouse selection. If Druid is a candidate OLAP store and the team is PHP-centric, this repo is evidence that tooling maturity is low and client work must be budgeted as part of the platform decision, not deferred to later.
• Roadmap scoping. Informs the effort estimate for a production client: retries, PSR-18 transport, auth/TLS, PHP 8 support, and the Druid SQL endpoint (GA after this package's last release) are all out of scope of the original code.

When to Consider This Package

Consider it (narrowly):

• As a read-only reference or fork seed to understand Druid's native query JSON and a plausible query-builder + HTTP transport structure in PHP.
• For a time-boxed proof of concept validating that a legacy PHP app can reach Druid and render a dashboard, where the PoC will be discarded.
• When you already run Druid and have an existing PHP codebase you cannot restructure, and you need a starting skeleton rather than a blank file.

Look elsewhere / do not adopt when:

• You need a maintained dependency — last release June 2017, repo archived, no issue triage, no security response.
• You require PHP 8+, PSR-18/PSR-17 interoperability, typed DTOs, or modern static analysis — none of which this predates.
• You need Druid SQL (the SQL endpoint postdates this client), authentication/TLS, retry/backoff, connection pooling, or observability hooks.
• License cannot be cleared by legal — the NOASSERTION designation is a hard stop for redistribution or embedding.
• You are evaluating it on community validation — 33 stars and 0 dependents is not a signal of fitness; treat adoption as effectively zero.
• Your roadmap includes multi-warehouse or vendor-portable analytics — a bespoke Druid-only client is a lock-in you should price explicitly.

How to Pitch It (Stakeholders)

For executives: This is a small, 2017-era PHP client for the Druid analytics database, published by a game studio and since archived. It is not a strategic dependency and carries no vendor support; its license is unclassified and needs legal review before any reuse. Its value is as a low-cost design reference, not a platform bet. Expect a modest in-house build (roughly one to two sprints for a production-grade client) if Druid stays on the roadmap for PHP-facing analytics.

For engineering: Use it as a blueprint. It illustrates the native-query JSON contract and a reasonable query-builder/transport split. Do not composer require it in production: fork or vendor the source, replace the transport with PSR-18, add PHP 8 types, add the Druid SQL path, and write contract tests against a pinned Druid version. Decide first whether queries live in the app or behind a dedicated analytics service — that architectural call matters more than the client itself.

Recommendation: Do not adopt as a dependency. Evaluate as a reference implementation, resolve the license question up front, and make the app-client vs. query-service decision before committing engineering time.