C Pchart Laravel Package

Technical Evaluation

Architecture fit. szymach/c-pchart is a Composer/PSR-4 modernization of the legacy pChart 2.0 library — it is a server-side chart rasterizer, not a charting framework. Input is a dataset plus imperative config; output is a GD image resource or a binary PNG/JPEG string. That puts it at odds with idiomatic Laravel request flow: rendering is synchronous, CPU-bound, and driven by global/static configuration objects. It fits cleanly only when wrapped behind a service class, dispatched through a queue, and fronted by a cache. Calling it inline from a controller is an anti-pattern that will surface as latency spikes under load.

Integration feasibility. Feasible, but the entire integration surface belongs to us. There is no Laravel service provider, no facade, no publishable config, no Blade directive, and no queue awareness. The package requires ext-gd (with FreeType for TrueType fonts), shipped font files, and a writable cache/output directory. A production-ready adapter is a small, well-bounded build — roughly one service class, one config file, and an optional facade.

Technical risk.

• Licensing (highest order). GPL-3.0 is copyleft. For an internally deployed proprietary SaaS this is usually tolerable, but any on-prem, appliance, or white-label distribution triggers source-release obligations for the combined work. This must be resolved by legal before engineering effort is committed; it is a decision gate, not a footnote.
• Legacy core. PSR naming is not modernization. Static/global state, no dependency injection, no PSR-3 logging, and no test seams make the library hard to unit test and hard to swap.
• Raster-only. No SVG, no client-side interactivity, no tooltips or zoom. If the product surface requires exploratory charts, this is the wrong tool regardless of integration cost.
• Maintenance trajectory. 150 stars and a low opportunity score indicate limited ecosystem momentum; upstream pChart 2.0 is long abandoned and this fork is thin. Assume a low bus factor and plan for fork-and-patch.
• Cache-key ownership. Output has no inherent versioning — invalidation, dimension caps, and determinism are ours to design.

Key questions.

1. Is the requirement static server-rendered images (PDF reports, transactional emails, exports) or interactive charts? Interactive → stop here and use a JS library.
2. Will this application ever be delivered outside our organization? If yes, GPL-3.0 review is a blocking gate.
3. What is expected chart volume and acceptable p95 latency? This determines queue and cache architecture.
4. Which typefaces and locales (CJK?) must render, and who owns font licensing?
5. What is our exit plan if the package stalls — is our abstraction thin enough to swap renderers without touching product code?

Integration Approach

Stack fit. Installs via Composer with effectively zero transitive dependencies, so collision risk with the Laravel dependency graph is negligible. Namespaced classes (szymach\cPChart\…) coexist with application code without autoload conflicts. It does not participate in Laravel's container — we own the wiring.

Migration path. If existing pChart 2.0 code is in place, this fork is the lowest-friction upgrade available: primarily namespace rewrites (pChart → szymach\cPChart\pChart, pData → szymach\cPChart\pData) plus Composer autoload. For greenfield use, treat it as an implementation detail: define a ChartRenderer contract with a PChartRenderer implementation so the library never leaks into domain code.

Compatibility. Confirm the PHP version against the fork's CI matrix, verify the GD build has FreeType enabled, and pin the package version explicitly. The most common runtime surprise is font resolution — test with the exact TTF files that will ship, not system defaults.

Sequencing.

1. Legal gate on GPL-3.0 disposition — no engineering before a decision.
2. Spike: render three representative chart types; measure visual quality, memory, and wall-clock time.
3. Contract + adapter + config, with the library fully behind an interface.
4. Queue + cache layer: cache key derived from a hash of the render spec, TTL tuned to data volatility.
5. Response layer: disk path with signed URL, or data: URI for email/PDF embedding.
6. Observability: render duration, failure rate, cache hit ratio, memory high-water mark.
7. Rollout behind a feature flag; parallel-run against incumbent output if replacing.

Operational Impact

Maintenance. Low-velocity upstream. Budget for the realistic case where we become the de facto maintainers of our fork: a dependency-watch process, a documented patch path, and a pinned version. Keep coupling shallow so a replacement is a contained change.

Support. No commercial support; community only. First-line support and the adapter layer are ours. Ramp-up is the hidden cost — pChart 2.0's imperative, global-config API is idiosyncratic, so even with clean namespacing a mid-level engineer needs several days to become productive.

Scaling. Rendering is CPU- and memory-bound; GD materializes the full bitmap in memory, so a large canvas can consume tens of MB per render. Mitigate with hard dimension caps, aggressive caching, and a dedicated worker pool so chart jobs cannot starve other queued work. Target a cache hit ratio above 90% for recurring report specs and design the key accordingly.

Failure modes.

• GD or FreeType missing/misconfigured → total render failure.
• Missing font files → silent fallback to bitmap fonts or garbled glyphs (worst class of bug: passes in dev, ships broken output).
• Output directory not writable or not shared across pods → inconsistent behavior in multi-node deploys.
• Oversized charts → worker memory exhaustion; needs memory_limit headroom plus dimension guards.
• Degenerate datasets (empty series, single point, NaN) → corrupted output without explicit guardrails.
• GPL obligations missed at distribution time.

Ramp-up. Roughly 2–4 engineer-days for a competent Laravel developer to ship a working adapter with caching; 1–2 weeks to production-hardened with observability and edge-case handling. Legal review runs as a separate, potentially blocking track. Recommend a one-week spike with an explicit go/no-go before this enters the roadmap.