Newest first, grouped by year. Search or filter by topic.
Trill's push service fans stories out with a single System.Threading.Channels queue - which means every connected browser competes for the same message instead of all receiving it, and the class name is plural while the field is not.
DShop runs a whole SignalR service to push operation results to the browser in real time - JWT handshake, per-user groups, Redis backplane. No frontend connects to it, and both UIs sleep through eventual consistency instead.
KC Star V5's third star is keyed by a polymorphic ReferenceId and a hierarchy-level string, fed by real-time triggers, and tracked by an update log with a PENDING to COMPLETED status - a queue that isn't actually a queue. Closing the V5 series.
The retrospective: after ten parts inside DevMentors' real-time feeds sample, the honest scorecard - five decisions worth stealing for real systems, the sharp edges catalogued in one place, and the concrete backlog that separates this teaching codebase from a production deployment. Part 11 closes the FeedR deep dive.
FeedR ships three ways to run its six services - pm2, Project Tye, and a deliberately split pair of docker compose files - plus per-service Dockerfiles and an environment-keyed configuration layer that lets the same build run on localhost and inside a compose network. Part 10 of the FeedR deep dive.
FeedR threads a correlation ID from a YARP transform through HTTP middleware and into Pulsar message metadata - and quietly loses it at the Redis hop in the middle. Tracing exactly where the chain holds and where it breaks is the best observability lesson in the sample. Part 8 of the FeedR deep dive.
How do you assert that an endpoint published an event when publishing is a side effect with no return channel? FeedR's end-to-end test answers with WebApplicationFactory, a real Redis round-trip, and a TaskCompletionSource - plus the timeout and determinism traps the sample leaves open. Part 9 of the FeedR deep dive.
Where FeedR's data graduates from tick to fact: the aggregator's pricing handler, a second messaging seam with envelopes and metadata, Apache Pulsar as the durable tier, and the notifier's acknowledge-as-you-go consume loop. Part 7 of the FeedR deep dive.
FeedR pushes live prices to clients through a gRPC server stream: a four-message proto contract, fixed-point decimals, dual Kestrel endpoints, and an event-to-stream bridge that busy-spins - plus the channel-based rewrite it's asking for. Part 5 of the FeedR deep dive.
FeedR's weather feed is the pattern for every external integration: poll a REST API inside an IAsyncEnumerable, guard it with a typed HttpClient and Polly retries, translate its JSON at the boundary, and republish it as a push. Plus the retry clause I can't defend and a hard-coded API key with a lesson in it. Part 6 of the FeedR deep dive.
FeedR moves every tick between services through a two-method streaming abstraction with a no-op default and a Redis implementation - which, despite the namespace, is pub/sub rather than streams. What that seam buys, how DI last-wins overrides it, and what you lose when nobody is listening. Part 4 of the FeedR deep dive.
How FeedR's quotes feed decouples a microsecond HTTP endpoint from an hours-long price generator: System.Threading.Channels as a command queue, marker records as the protocol, and an Interlocked flag for idempotent start/stop. Part 3 of the FeedR deep dive.
FeedR's API gateway is a YARP reverse proxy whose entire routing table lives in appsettings.json - prefix-stripping routes, per-environment cluster overrides, and a one-line transform that starts every distributed trace. Part 2 of the FeedR deep dive.
A guided tour of FeedR, DevMentors' open-source .NET microservices sample for real-time data feeds - six services, Redis pub/sub, Apache Pulsar and a gRPC stream, and the two-tier eventing model that makes it worth reading. Part 1 of a source-level deep dive.
