Feed Io Laravel Package

Product Decisions This Supports

• Build vs. buy for feed ingestion. If a roadmap item contains "import posts from external blogs," "aggregate industry news," "syndicate our content," or "podcast distribution," this package collapses what is normally a multi-sprint effort (parsers, format detection, date normalization, redirect handling, conditional GET) into roughly days of integration work. The alternative — hand-rolling SimpleXML parsing — reliably fails on the long tail: malformed feeds, missing timezones, relative links, ambiguous GUIDs, encoding quirks.
• Scope the feature in both directions. Most feed libraries only read or only write. feed-io does both across RSS, Atom, and JSON Feed, which means one dependency can serve two distinct roadmap bets: ingestion (content import, news aggregation, competitor monitoring) and distribution (syndicating your own content into aggregators, Google News-style consumers, podcast directories).
• De-risk onboarding UX with autodiscovery. discover($url) resolves feeds from a page's HTML headers. That supports a "paste a URL, we'll find the feed" flow — a meaningfully better activation path than asking a user to locate and paste an RSS URL themselves.
• Cost control as a product decision, not an infra detail. Conditional HTTP headers (If-Modified-Since) plus getNextUpdate() scheduling (average/median interval heuristics, "sleepy feed" backoff) let you justify a polling cadence with real numbers. This directly informs whether a feature is economically viable at N thousand sources, and it's a lever you can tune rather than a black box.
• Incremental sync semantics out of the box. getItemsSince() and composable filters (Since, custom Database filter) map cleanly onto "only surface new items to users" and "don't re-notify on old content" — requirements that otherwise surface late and force a data-model rewrite.
• Format roadmap without re-platforming. JSON Feed support matters for modern readers and JS clients; getPsrResponse() gives you a correct, cacheable HTTP response in a controller without you reasoning about content types and ETags. The format a customer asks for is a config value, not a migration.
• Media/podcast adjacency. Enclosure and Media support plus custom namespace (itunes) handling opens podcast distribution as an adjacent bet without a separate stack.
• Architecture decision: framework neutrality. This is a PSR-composed library (PSR-3 logger, PSR-18 HTTP client, PSR-7 responses), not a Laravel package. That supports a stated position of "core capability stays framework-agnostic; Laravel is our delivery surface." The trade-off you are explicitly accepting is that you own the glue: a service provider, a config file, an Eloquent persistence layer, a queued polling job, and a PSR-18 bridge (Laravel ships Guzzle, so route through the Guzzle adapter or an HttplugClient wrapper). Budget this as real work in the estimate, not as incidental.

When to Consider This Package

• Adopt when you need read and write, more than one format, incremental fetching, and you want to avoid owning parser maintenance. The combination of format detection, HTTP caching, redirect handling (added in 6.2 with loop protection and relative URL support), date/timezone correction, and autodiscovery is genuinely tedious to replicate and easy to get subtly wrong.
• Adopt when the feature is a means to an end — the value is in what you do with items (search, dedupe, ranking, notifications), not in the parsing itself. Every hour spent on feed parsing is an hour not spent on the differentiator.
• Adopt when a thin wrapper is acceptable. Because it's framework-agnostic and small in surface area, you can put it behind your own FeedReader/FeedWriter interface and retain the option to swap to a hosted service later.
• Look elsewhere when you only need to read one or two known, well-formed feeds — simplexml or a hosted conversion API is cheaper than a dependency plus glue.
• Look elsewhere when the requirement is really push, not pull. There is no WebSub/PubSubHubbub here; real-time freshness means a different architecture (hub subscription or a hosted aggregator such as Superfeedr/Feedly).
• Look elsewhere when the requirement is content extraction. Feed bodies are often truncated summaries; full-text readability is a separate library and a separate estimate.
• Look elsewhere when you need social-source coverage. Twitter/X, LinkedIn, Instagram and similar are API integrations (with auth, rate limits, and terms), not feed problems. Scope these as separate bets or cut them.
• Look elsewhere when you need vendor support, an SLA, or a large hiring pool. MIT license, 23 stars, and 0 dependents signal a small, maintainer-led project. That's fine for a non-critical path; it's a governance question for revenue-critical infrastructure.
• Check the version floor first. v6 requires PHP 8.1+; older pins exist (5.x for 8.0, 4.x for 7.1). Confirm alignment with your Laravel/PHP support matrix before committing the estimate.
• Watch the schedule risk signal. Releases are dependency-update-heavy (v6.3.1 is "only dependency updates"), which reads as maintained but low-velocity on features. Expect few new capabilities; plan to build the Laravel-side product features (persistence, dedupe, ranking, UI) yourself.

How to Pitch It (Stakeholders)

For executives — one paragraph: "Feeds are a solved problem that's expensive to solve badly. This MIT-licensed library gives us reading and writing across RSS, Atom, and JSON Feed — the three formats every aggregator, podcast directory, and news consumer asks for — plus the unglamorous parts that eat sprints: format detection, redirect handling, date normalization, and bandwidth-saving incremental fetches. It's roughly a two-to-three-day integration plus a sprint of Laravel glue, versus an estimated three to five sprints to build and harden in-house. The honest caveat is community size: 23 stars and no downstream dependents means we're adopting a focused, maintainer-led library, not a platform. We mitigate that by wrapping it behind our own interface, pinning the version, and keeping the swap path to a hosted service open. Net recommendation: adopt behind an abstraction, ship the feature, revisit in two quarters with real usage data."

For engineering — the short version:

• It's framework-agnostic and PSR-composed: PSR-3 logger, PSR-18 HTTP client, PSR-7 responses. No Laravel coupling, no service container assumptions, no global state.
• Small, explicit constructor injection (new FeedIo($client, $logger)) — trivially testable; the HTTP client is the seam you stub in tests. The deprecated Factory is gone as of 6.0, so instantiate the facade directly.
• Requires PHP 8.1+ on v6. You'll need a PSR-18 bridge; Laravel ships Guzzle, so use the Guzzle adapter or wrap HttplugClient.
• Where it earns its place: redirect handling (301/302/303/307/308 with loop protection and relative URLs), isPermaLink GUID-to-link resolution, whitespace/relative-link normalization, invalid-JSON guards, and the getNextUpdate() interval heuristics you'd otherwise never get around to writing.
• Known extension points we'll actually use: getFilteredItems() with a Chain of filters (since-filter plus our own DB-backed dedupe), discover() for URL onboarding, getPsrResponse() for the serving endpoint, and custom namespaces for iTunes/podcast metadata.
• What we own: Eloquent models and migrations for sources and items, a queued poller driven by getNextUpdate(), a feed-formatting controller, and observability around fetch failures and parse errors. None of that is in the package.
• Risk posture: active but low-velocity maintenance, single-maintainer-shaped bus factor, thin community answers. Pin the version, contain the dependency behind an internal interface, and treat an upgrade as a scheduled task rather than a drive-by.

Success metrics to define before kickoff: time-to-first-successful-feed-import, number of distinct sources onboarded, fraction of polls returning 304 (cached) versus 200, median latency from source publication to our item appearing, and per-source ingestion failure rate. These tell you within a quarter whether the build-versus-buy call was right — independent of how the library itself performs.