Feed Bundle Laravel Package

Getting Started

First, the reality check. mopa/feed-bundle is a Symfony bundle, not a Laravel package. There is no ServiceProvider, no config/feed.php to publish, no facade, no php artisan commands that will appear in your app. It was built for the Symfony 2.x service container, Doctrine MongoDB ODM, and a Ratchet-based websocket server, and it carries 0 stars / 0 dependents — treat it as an abandoned reference implementation, not a dependency.

That leaves two realistic entry points:

1. Sidecar (only if you genuinely need the bundle's code): create a small standalone Symfony app pinned to whatever Symfony/PHP versions its composer.json allows, enable the bundle in that app's kernel, configure Doctrine MongoDB ODM plus the mopa_feed config block, and run its websocket console command as a long-lived process. Your Laravel app talks to it over HTTP/Redis, never over Composer.
2. Port the ideas (recommended for ~95% of cases): read the bundle, then implement the same shape with Reverb/Pusher + Eloquent (or mongodb/laravel-mongodb).

Where to look first, in order:

• composer.json — the hard version ceilings. If it demands Symfony 2.x and PHP 5.x, the sidecar path is likely dead too, and you're in "reference only" territory.
• Resources/config/ — the service definitions tell you the real architecture faster than any README: which service builds feed items, which one persists them, which one broadcasts.
• The feed builder/manager service and the Doctrine event subscriber that hooks entity persistence — that's the core loop.
• The websocket server command + the shipped JS client asset — that's the transport contract.
• Only then the README on phiamo/FeedBundle.

First use case to validate the concept: "new comment on a post" → append a feed item → push it to everyone subscribed to that post's feed. If you can't trace that path end-to-end in an afternoon, stop and port instead.

Implementation Patterns

Feed model. The bundle's mental model is an activity stream: feed items reference a source entity by class + id (plus a type/timestamp), and are grouped into feeds (per-user, per-object, or global). This is fan-out-on-write — every relevant event materialises one row/document per subscriber feed. Copy that schema even if you don't copy the code.

Annotation-driven sources → Laravel observers. The bundle marks entities with annotations so a listener auto-generates feed items on persist. The Laravel equivalent is an Observer (created/updated) or a domain event + listener. Prefer explicit events — annotations are the part of this package that aged worst (@Feed docblocks vs. PHP 8 attributes).

Bridging Laravel to a sidecar. Never call the sidecar inside a DB transaction. Write to an outbox table (or dispatch a queued job with afterCommit()), then have the job POST to the socket service or publish to Redis. Payload should be minimal: {feed_id, item_id, type, actor_id, occurred_at, payload}.

Channel naming and subscription. One channel per feed id (feed.post.42, feed.user.7). The client sends a subscribe frame; the server authorises it. Do not trust client-supplied channel names or ids — authorise every subscription server-side against the same rules your Laravel policies/Broadcast::channel callbacks enforce.

Auth across framework boundaries. A shared session is not realistic between a Laravel app and a Symfony sidecar. Issue a short-lived signed token (HMAC or JWT) from Laravel, pass it in the websocket handshake, and validate + authorise on the socket server at subscribe time. Refresh before expiry and reconnect.

If you port, the mapping is one-to-one:

Scaling notes that apply either way: fan-out belongs on a queue worker, not the request cycle; run multiple socket nodes behind a load balancer only with Redis pub/sub to fan messages across nodes; and cap fan-out per event (see gotchas).

Gotchas and Tips

• Composer will not save you. Laravel 10/11 requires modern Symfony components; this bundle's constraints almost certainly conflict. Don't attempt composer require mopa/feed-bundle in your app "just to read the source" — vendor it into a scratch directory or read it on GitHub.
• MongoDB ODM is a hard dependency. You get a second datastore, no foreign keys, and orphaned feed items whenever a source entity is deleted. Plan a cleanup job or soft-delete + tombstone items; the bundle won't do it for you.
• Fan-out explodes. One document per follower per event is fine at 50 followers and fatal at 50,000. Cap it, or switch high-degree actors to fan-out-on-read (merge on fetch). This is the single biggest design decision and the bundle gives you no knob for it.
• Idle websocket connections die. Proxies, load balancers, and mobile networks kill quiet sockets. Ping/heartbeat every ~30s, reconnect with exponential backoff + jitter (otherwise every client reconnects in the same second), and always support a REST fallback for "load the feed" and "load missed items since $lastItemId".
• Make delivery idempotent. At-least-once is unavoidable; clients should dedupe by item_id, and ordering ties on identical timestamps need a secondary sort key.
• Debugging is harder than usual. The socket server logs to stdout, not to Laravel's log or Telescope. Use supervisorctl tail, and inspect frames in browser DevTools → WS, or wscat. Persist every broadcast payload to a log table for a week — replaying a real payload beats reasoning about it.
• Config quirks if you keep the bundle alive: register the ODM bundle before the feed bundle, point the feed config at the correct document manager name explicitly, and check mapping config — a silent wrong-manager is the classic "items never persist, no error" failure.
• Expect to fork. With 0 stars and 0 dependents there is no upstream to lean on: vendor-patch or fork, pin the commit, and write down why. Don't leave a floating version constraint in a composer.json you'll inherit in two years.
• The real deliverable is the architecture. The valuable thing here is the pattern — declarative feed sources, item documents referencing entities by class+id, push-on-persist, per-feed channels — not the code. Copy the shape into Laravel-native tooling and you retain all the leverage with none of the maintenance debt.