Feed Parser Laravel Package

Technical Evaluation

What shipped: JustSteveKing/feed-parser 0.0.1 — an initial public release of a PHP feed parser with "basic support" for RSS and Atom. This is the first cut, not an increment on prior code we have assessed.

Architecture fit

• The capability (ingest RSS/Atom into a Laravel application) is a common, low-differentiation need. Value is therefore concentrated in how it integrates — discovery of the parser, DTO/collection ergonomics, error handling, and whether output maps cleanly onto our domain models — none of which is described in the release notes.
• It is a single-responsibility library rather than a framework-coupled feature bundle, which is architecturally the right shape for us: it can sit behind an interface in our ingestion layer and be swapped out.
• Unknown whether it ships a Laravel service provider, facade, or config file. If it is framework-agnostic PHP, we own the wiring; that is acceptable but must be budgeted.

Integration feasibility

• Low conceptual complexity: feed in, structured entries out. No infrastructure, no daemon, no persistent state expected.
• Composer-installable from Packagist/GitHub; integration effort is likely measured in hours-to-days for a spike, not weeks.
• Feasibility is gated by one unknown: output shape. If it returns arrays or SimpleXML nodes rather than typed objects, downstream mapping cost rises materially.

Technical risk

Key questions

1. Is there a Laravel service provider, facade, and publishable config — or must we wire it manually?
2. What is the return type — typed DTOs/value objects, associative arrays, or raw SimpleXMLElement?
3. Which namespaces/extensions are supported (Media RSS, Dublin Core, iTunes, GeoRSS), and does it fail loudly or drop unknown elements silently?
4. Does it fetch remote URLs itself, or parse a string/stream we supply? (The latter is strongly preferred — it keeps HTTP client, timeouts, retries, and SSRF policy under our control.)
5. How are parse errors surfaced — exceptions, result objects, or false?
6. Is libxml external entity loading disabled, and is there a size/entity guard?
7. Is there a test suite and CI, and what is the maintainer's stated support/versioning intent toward 1.0?

Integration Approach

Stack fit

• Assumes a standard Composer/Laravel application on PHP 8.x. Direct fit for any ingestion service, scheduled command, or queue worker that needs to normalise third-party feeds.
• Natural home: behind a FeedSource/FeedParser port in our domain layer, with the package as one adapter. This contains the pre-1.0 blast radius to a single class.

Migration path

• Greenfield integration — no migration of existing data or code.
• If we already have ad-hoc simplexml_load_file parsing in-house, treat the package as a replacement candidate only after a side-by-side comparison on our real feed corpus. Do not rip out working parsers for a 0.0.1.
• Wrap from day one: pin the dependency in composer.json with an exact or tilde constraint (0.0.1, not ^0.0), and expose only our own interface to callers so a future swap or fork is a one-file change.

Compatibility

• Pin exactly. Pre-1.0 semver permits breaking changes on 0.0.x → 0.0.y; a tilde on 0.0.1 still allows 0.0.x drift, so prefer 0.0.1 as an exact constraint and upgrade deliberately.
• Verify PHP version support against our runtime matrix before committing.
• Confirm ext-libxml/ext-simplexml are present in all target environments (including CI and any containerised workers) — a classic late-breaking surprise.

Sequencing

1. Spike (1–2 days): install in a scratch app, parse five representative feeds from our actual sources — a clean RSS 2.0, a clean Atom, a podcast feed with iTunes tags, a WordPress feed with Dublin Core, and a deliberately malformed one. Record what survives and what is dropped.
2. Security review: confirm XXE/entity-expansion handling and that remote fetching (if any) is not the package's responsibility.
3. Adapter build: implement our FeedParser interface over the package, with normalisation to our own DTOs.
4. Shadow mode: run in parallel with the current mechanism on production feeds for two weeks; diff outputs before cutting over.
5. Cut over behind a feature flag, with a documented fallback to the in-house path.

Gate steps 3–5 on the spike answering the output-shape and error-handling questions. If the package fetches URLs itself or returns raw XML nodes, re-scope before proceeding.

Operational Impact

Maintenance

• Ongoing cost is dominated by dependency hygiene, not by our own code: expect to track a fast-moving 0.0.x API and to re-verify on every bump.
• Budget a standing allowance for replacing this package, not just upgrading it. A single-maintainer, pre-1.0 library should be treated as a candidate for absorption — the code is likely a few hundred lines, and vendoring or forking is a credible exit.

Support

• No vendor. Support is the maintainer's goodwill plus our own reading of the source. Escalation path: upstream issue → fork.
• Before production use, establish an internal owner for the adapter and a documented "if this breaks, we do X" runbook.

Scaling

• Feed parsing is CPU-bound and short-lived; throughput scales horizontally with workers, not with anything the package does. Fine for our volumes (feeds, not request-per-user traffic).
• The real scaling constraint is outbound HTTP: rate limits, per-host concurrency, and politeness on scheduled polling. Keep fetching outside the package and under our queue and backoff policy.
• Memory is proportional to feed size — large podcast/video feeds with hundreds of entries will spike. Enforce a max response size and per-feed entry cap.

Failure modes

Silent field loss is the failure mode to design against. It produces plausible-looking output that is wrong, which is far more expensive than a crash.

Ramp-up

• For a competent Laravel engineer: under a day to be productive, largely because there is no documentation and they will read the source.
• Add half a day for the adapter and DTO mapping, and a day for the feed-corpus spike.
• No new infrastructure, no new runtime, no operational training beyond the runbook.

Recommendation: Adopt for evaluation and low-stakes internal ingestion only. Proceed to production for non-critical feeds after the spike, security review, and shadow-mode comparison. Do not place this on a critical path — customer-facing content pipelines or anything where silently missing fields cause commercial harm — until it reaches a stable release or we have absorbed the code. Re-assess on the next release, and specifically on whether typed output, namespace support, and error semantics have stabilised.