# Publish-subscribe pattern The publish-subscribe pattern (short: pubsub) is an event handling and messaging pattern where the consumer subscribes to the provider, which in return can then publish a message that can be picked up and processed by each subscribed consumer. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## EP224: MCP vs RAG vs AI Agents DevFeed: [EP224: MCP vs RAG vs AI Agents]() Original publisher: [Read original article]() Author: ByteByteGo Published: 2026-09-05T15:30:58Z Content type: article Language: en Sources: [ByteByteGo]() Topics: [AI Agent](), [Model Context Protocol](), [Retrieval Augmented Generation (RAG)](), [distributed-systems](), [Publish-subscribe pattern](), [Replication]() Tags: [ai-agent](), [distributed-systems](), [mcp](), [messaging](), [rag](), [replication]() ### AI overview This article compares MCP, RAG, and AI agents. It explains MCP as a standard protocol for connecting AI models to external tools and data, RAG as a way to retrieve current information from external sources, and AI agents as systems that perform tasks and make decisions autonomously. It also summarizes several distributed-systems patterns, including replication, sharding, publish-subscribe, circuit breakers, retries, and leader election. ### Source excerpt An AI agent is kind of an AI system where the agent performs the task autonomously and takes the decisions. ## We turned off Pub/Sub and nobody noticed DevFeed: [We turned off Pub/Sub and nobody noticed]() Original publisher: [Read original article]() Author: Patrick Hamann; Mike Fisher Published: 2026-08-11T13:56:40Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [event driven](), [Messaging](), [Publish-subscribe pattern](), [Availability](), [systems](), [Apache Pulsar](), [Cloud](), [Google]() Tags: [availability](), [broker](), [cloud](), [event-driven](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [messaging](), [outage](), [post-mortem](), [production](), [scale](), [slack](), [slack-incident]() ### AI overview This developer article explains how incident.io made its predominantly event-driven platform more resilient by adding a secondary message broker alongside Google Cloud Pub/Sub. It describes the role of message brokers and publish-subscribe processing, the risks of a single point of failure, and the successful production test in which Pub/Sub was turned off without affecting customers. ### Source excerpt Our entire event-driven platform ran through a single message broker, which made it a single point of failure. So we added a second one. This is the story of building an event load balancer, the queuing theory behind it, and the final chaos test where we turned off Pub/Sub in production and nobody noticed. ## How Discord Fans Out One Message to a Million Users DevFeed: [How Discord Fans Out One Message to a Million Users]() Original publisher: [Read original article]() Author: Nikki Siapno Published: 2026-07-07T13:22:26Z Content type: article Language: en Sources: [Level Up Coding System Design Newsletter]() Topics: [Discord](), [Publish-subscribe pattern](), [real-time](), [WebSocket](), [Back end](), [Processes](), [Authorization]() Tags: [backend](), [case-study](), [channel](), [discord](), [engineering](), [permission](), [real-time](), [scale](), [server](), [websocket]() ### AI overview This case study explains how Discord fans out a single message to many online users. It describes a real-time backend built around pub/sub, guild routing processes, permission checks, session processes, and WebSocket delivery. ### Source excerpt A case study in fanout, bottlenecks, and the engineering decisions behind Discord's scale. ## When the sensor starts thinking: SnortML, agentic AI, and the evolving architecture of intrusion detection DevFeed: [When the sensor starts thinking: SnortML, agentic AI, and the evolving architecture of intrusion detection]() Original publisher: [Read original article]() Author: Samaresh Kumar Singh Published: 2026-07-06T15:23:34Z Content type: article Language: en Sources: [Stack Overflow Blog]() Topics: [Machine Learning & Artificial Intelligence](), [Security](), [Cisco Talos](), [Network](), [Inference](), [Publish-subscribe pattern](), [Architecture & Design]() Tags: [ai](), [architecture](), [cc-by-sa](), [cisco-talos](), [inference](), [machine-learning](), [network](), [se-stackoverflow](), [se-tech](), [security]() ### AI overview The article examines how SnortML adds local machine-learning inference to Snort 3's intrusion-detection pipeline. It contrasts signature-based detection, which provides precise coverage for known exploits, with machine-learning detection aimed at identifying novel or modified attack behavior. It also places SnortML alongside the broader rise of agentic AI in network defense, while treating the two as developments operating at different architectural layers. ### Source excerpt Signature-based detection has always known what it was looking for. Machine learning and autonomous agents are changing the question entirely, shifting from "does this match a known pattern?" to "does this actually make sense in context?" ## An Interactive Study of Publish/Subscribe Messaging for Event-Driven Backend Systems DevFeed: [An Interactive Study of Publish/Subscribe Messaging for Event-Driven Backend Systems]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-04-24T00:00:00Z Content type: tutorial Language: en Sources: [Encore Updates]() Topics: [Publish-subscribe pattern](), [Messaging](), [Back end](), [distributed-systems](), [event driven]() Tags: [decoupling](), [developers](), [distributed-systems](), [event-driven](), [events](), [flow](), [messaging](), [patterns](), [publisher](), [subscriber]() ### AI overview An interactive tutorial explains publish/subscribe messaging by contrasting it with direct service calls. It shows how topics decouple publishers from subscribers, support fan-out, and let subscribers process messages independently, including when downstream services are unavailable. ### Source excerpt An interactive study of publish/subscribe messaging ## Heroku Eventing: A Router for All Your Events DevFeed: [Heroku Eventing: A Router for All Your Events]() Original publisher: [Read original article]() Author: Kim Harrison Published: 2025-03-04T15:01:00Z Content type: release Language: en Sources: [Heroku]() Topics: [Heroku](), [event driven](), [Publish-subscribe pattern](), [Authentication](), [API](), [Monitoring]() Tags: [api](), [app-architecture](), [architecture](), [authentication](), [event-driven](), [events](), [heroku](), [kafka](), [monitoring](), [news](), [observability](), [performance-optimization](), [product-features]() ### AI overview Heroku introduces Heroku Eventing, a pilot tool for managing, subscribing to, and publishing events across services. It provides a unified API, centralized event management, integrations with Heroku Kafka and Postgres, secure credential storage, and monitoring across connected sources. ### Source excerpt Managing event-driven architecture can be challenging. For many organizations, this includes a diverse set of eventing services and buses, often across multiple organizations. Developers must manage authentication and pub/sub services across teams and applications. We're thrilled to introduce Heroku Eventing, a powerful tool designed to help teams manage events more efficiently and securely. This new [...] The post Heroku Eventing: A Router for All Your Events appeared first on Heroku. ## Repost: The Real LISP Mobility Use Case DevFeed: [Repost: The Real LISP Mobility Use Case]() Original publisher: [Read original article]() Published: 2024-04-30T05:59:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [Lisp](), [BGP](), [networking](), [Publish-subscribe pattern]() Tags: [bgp](), [lisp](), [mobility](), [networks](), [protocol](), [routing]() ### AI overview The article discusses using LISP with PUBSUB for multilink mobility in ground-to-airplane networks. It argues that LISP may handle frequent mobility events, scale, and safety-critical requirements better than BGP in this use case, while noting that several protocol extensions and standardized reliable transport are still needed. ### Source excerpt Béla Várkonyi is working on an interesting challenge: building ground-to-airplane(s) networks providing multilink mobility. Due to its relative simplicity, he claims LISP works much better than BGP in that environment. In some newer routers BGP would not be such a big bottleneck, but you need a lot of knob turning in BGP to get it right, while in LISP it is quite simple. If you have many thousands concurrent airplanes with multi-link and max. 16 subnets with different routing policies on each, and the radio links are going up and down, then you have a large number of mobility events. Read more ... ## Build a Real-time Materialized View from Postgres Changes using Confluent's ksqlDB DevFeed: [Build a Real-time Materialized View from Postgres Changes using Confluent's ksqlDB]() Original publisher: [Read original article]() Author: Evan Shortiss Published: 2024-02-28T17:33:42Z Content type: tutorial Language: en Sources: [Blog -- Neon Docs]() Topics: [Kafka](), [Replication](), [Streaming](), [real-time](), [Messaging](), [Microservice](), [data](), [Databases](), [Cloud](), [Architecture & Design](), [Publish-subscribe pattern](), [ide]() Tags: [apache-kafka](), [architectures](), [cloud](), [community](), [components](), [confluent](), [confluent-cloud](), [data](), [events](), [messaging](), [microservices](), [performance](), [postgres](), [real-time](), [replication](), [sql](), [streaming]() ### AI overview This tutorial explains how to stream changes from a Neon Postgres database to Apache Kafka and use ksqlDB on Confluent Cloud to build a real-time materialized view. It contrasts this approach with refreshing a Postgres materialized view after each write, highlighting performance, history retention, and reliable downstream notifications. ### Source excerpt Neon's support for Postgres' logical replication features opens up a variety of interesting use cases, including for real-time streaming architectures based on change data capture. We previously demonstrated how to use Debezium to fan-out changes from Postgres by using Redis as a... ## Fan-out from Postgres with Change Data Capture using Debezium and Upstash Redis DevFeed: [Fan-out from Postgres with Change Data Capture using Debezium and Upstash Redis]() Original publisher: [Read original article]() Author: Evan Shortiss Published: 2024-02-14T23:32:41Z Content type: tutorial Language: en Sources: [Blog -- Neon Docs]() Topics: [Publish-subscribe pattern]() Tags: [community](), [database](), [event-driven](), [messaging](), [node-js](), [postgres](), [redis](), [replication](), [serverless](), [streams]() ### AI overview A tutorial on using Postgres logical replication and change data capture with Debezium Server and Upstash Redis Streams to implement fan-out messaging with at-least-once delivery. ### Source excerpt Neon now has beta support for Postgres Logical Replication. This enables teams to use Change Data Capture (CDC) to observe database changes - such as INSERT and UPDATE operations - and stream these changes to downstream systems. We previously wrote about the benefits of CDC and h... ## Using Stand-by Servers for Postgres Logical Replication DevFeed: [Using Stand-by Servers for Postgres Logical Replication]() Original publisher: [Read original article]() Published: 2023-12-19T00:00:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Replication](), [Database](), [Availability](), [Streaming](), [Publish-subscribe pattern]() Tags: [postgres](), [replication](), [servers]() ### AI overview This tutorial explains Postgres logical replication from stand-by servers, including how replication supports high availability and load distribution. It contrasts logical replication with streaming replication and introduces the publish/subscribe model. ### Source excerpt Table of Contents What is Postgres Logical Replication? Why Logical Replication On Stand-By Servers? Provisioning a Testing Environment Testing Things Out This post originally appeared on the Decodable blog. All rights reserved. For users of Change Data Capture (CDC), one of the most exciting features in Postgres version 16 (released in September this year) is the support for logical replication from stand-by servers. Instead of connecting to your primary server, you can now point CDC tools such as Debezium to a replica server, which is very interesting for instance from a load distribution perspective. I am going to take a closer look at this new feature in this two-part blog series: ## Replay replay: Durable Execution, the way forward for event-driven architectures DevFeed: [Replay replay: Durable Execution, the way forward for event-driven architectures]() Original publisher: [Read original article]() Author: Jim Walker Published: 2023-10-24T06:00:00Z Content type: opinion Language: en Sources: [Temporal Blog]() Topics: [Publish-subscribe pattern](), [Developer experience](), [backend-development](), [Resilience]() Tags: [architecture](), [architectures](), [backend](), [business-logic](), [community](), [developer-experience](), [resilience]() ### AI overview A Replay 2023 keynote discusses using Temporal and Durable Execution to simplify event-driven architectures. The talk explains how an execution-centered design can reduce complexity and improve the developer experience while supporting scalable and resilient applications. ### Source excerpt At Replay 2023, our CEO and co-founder, Max provided an enlightening keynote talk that outlined how Durable Execution is the future of event-driven architectures. ## Mexico City Rails Meet-up Reboot DevFeed: [Mexico City Rails Meet-up Reboot]() Original publisher: [Read original article]() Author: Doximity Published: 2022-11-01T10:39:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Ruby on Rails](), [Kafka](), [Microservice](), [Architecture & Design](), [Publish-subscribe pattern](), [Bootcamp]() Tags: [architecture](), [developers](), [development](), [kafka](), [microservices](), [rails](), [ruby-on-rails](), [services]() ### AI overview This article describes the restart of the Mexico on Rails meetup in Mexico City after pandemic-related disruption. It covers the event, its attendees, a presentation on syncing data across Rails microservices, Kafka as publish-subscribe middleware, and discussion about software education and in-person community. ### Source excerpt In recent years Mexico City has developed a thriving tech scene, with new startups putting roots, vying for talent, and contributing to a slew of events and conferences in the city. Mexico on Rails meetup has been an integral part of the ecosystem, meeting regularly to connect and discuss Ruby on Rails and web development. But the pandemic put most of this activity on hold. While discussing this recently with my Doximity colleague Samus Gray, who also lives in Mexico City, he suggested we try and restart the meetup activity. I nodded along, as something that would be nice to do. A few days later, Samus had already convinced the previous meetup organizer to transfer the group to us, found a venue, and got Doximity to sponsor it. That's when I realized he meant it. Last week we met in Le Wagon, a Rails Bootcamp in the fashionable Roma Norte neighborhood. Despite a rainy day, about 20 people showed up. This was a diverse crowd of seasoned developers working for local startups such as Telos Labs and Jetty, Bootcamp students, and digital nomads working remotely. After breaking the ice over Detroit-style pizza and beers, we moved to a classroom, where I gave a presentation on data syncing between Rails microservices. Presented originally by our colleague Austin Story in RailsConf 2021, it tracked Doximity's thorny path from a monolith app with a limited number of data sources to an architecture in which multiple rails applications and services can consume and sync over billions of data updates from a myriad of sources. During the Q&A session, Samus shared his experience working with Kafka, Doximity's tool of choice for our publish-subscribe middleware. Finally, Le Wagon co-founder Mathiew Le Roux took the floor to share his vision for the future of software education. Eager to connect, most of us stayed long after the formal part was over, chatting and sharing our experiences. The enthusiasm shared by everyone for the meetup reboot was a reminder of the importance of meet ## Micro Service Events (AWS EventBridge vs. SNS) DevFeed: [Micro Service Events (AWS EventBridge vs. SNS)]() Original publisher: [Read original article]() Author: Kristian Müller Published: 2022-09-16T12:06:51Z Content type: comparison Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [event driven](), [Messaging](), [Amazon Web Services](), [Amazon Simple Queue Service (SQS)](), [Publish-subscribe pattern](), [Architecture & Design](), [AWS Lambda](), [Amazon API Gateway](), [DynamoDB](), [Amazon S3](), [TypeScript]() Tags: [api](), [api-gateway](), [architecture](), [aws](), [aws-eventbridge](), [aws-sns](), [data](), [data-processing](), [database](), [dynamodb](), [event](), [event-driven](), [eventbridge](), [eventbus](), [events](), [gateway](), [lambda](), [messaging](), [microservice-architecture](), [s3](), [sns](), [sqs](), [typescript]() ### AI overview This article examines Homegate's event-driven microservice architecture on AWS and compares Amazon SNS with EventBridge as messaging infrastructure. It describes how services use SNS, SQS, Lambda, API Gateway, DynamoDB, and S3, and explains that EventBridge has a different focus, so replacing SNS is not necessarily the right question. ### Source excerpt During the last few years, we've been busy rebuilding the Homegate platform in an event driven, micro service architecture based on AWS. One of the most important buildings blocks, or shall we rather say the mortar that connects the building blocks, is the way our services send events to each other. While Amazon offers its notification service SNS since more than 12 years; in 2019 it started a newcomer in the messaging bus field by introducing EventBridge. This was very interesting to us as we're using SNS a lot. Bus on a Bridge (Photo by "Blue Elf" on Wikimedia Commons) As EventBridge was introduced and gained traction we asked ourselves what advantaged we would gain by switching our SNS based service glue to EventBridge. Maybe this turned out to be the wrong question for us. Let's look at our system to see why. Micro Services Connected by SNS Homegate is connecting dozens of services via SNS right now. Those services range from single purpose Lambda functions written in TypeScript to database heavy services using Aurora or DynamoDB and Step Functions sending events to other services. Some of the services are also interfacing external APIs such as Salesforce or SendGrid. Here our Lambda functions can call APIs when needed. On the other hand, we have web services to be called as APIs by other systems and end users. This is mostly achieved via API Gateway. A typical service connects to the system by subscribing to events needed to fulfill its purpose. Those inbound SNS events are then ingested via SQS allowing for orderly data processing and DLQs to handle errors. Outgoing results are pushed back to the system in form of events to a SNS topics. As Marko Savic has pointed out, we're also utilizing S3 to store and replay those events if needed. Basic AWS Lambda function connected via SNS If we would replace the SNS topic by streams on the EventBridge we would initially gain the same functionality by utilizing SQS as well. However, EventBridge has a different focus. Let ## AWS FIFO Queues with Message Groups for Atomic Processing at Scale DevFeed: [AWS FIFO Queues with Message Groups for Atomic Processing at Scale]() Original publisher: [Read original article]() Author: Nick De Cooman Published: 2022-03-03T09:55:58Z Content type: tutorial Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [Amazon Simple Queue Service (SQS)](), [Amazon Web Services](), [Serverless](), [event driven](), [Scalability](), [Publish-subscribe pattern]() Tags: [architecture](), [aws](), [decoupling](), [distributed](), [event](), [event-driven](), [events](), [fifo](), [serverless](), [sns](), [sqs]() ### AI overview A tutorial on using AWS FIFO queues and message groups to process events for multiple objects in parallel while ensuring that only one instance processes events for the same object at a time. It presents a serverless architecture using SNS, SQS, and Lambda for atomic listing ingestion. ### Source excerpt How to process multiple objects in parallel with the guarantee that for each unique object, only a single instance is processed simultaneously In a distributed, event-driven architecture, many challenges arise when processing large sets of data. One of them is the need for scalability when handling event streams with a substantial throughput. The challenge becomes even more complicated when processing these events involves atomic operations. In this case, we cannot simply process multiple events in parallel. As an example, let's say that we are building a service that ingests listings into our platform. The ingestion process involves several steps and requires multiple API operations. As a result, the whole ingestion can take up to several seconds per listing to complete. Now, here is where it gets tricky: a constraint of our service is that, while we are processing a listing, we cannot process other events for the same listing. The ingestion should be considered an atomic operation, and hence, only a single execution per listing can be performed simultaneously. At Homegate, we run most of our infrastructure on AWS in a serverless fashion. At the core of this, Lambda functions execute application logic. A common pattern is to use SNS topics to fan-out messages, and SQS for acting as a decoupling buffer between an SNS topic and some Lambda function. For our ingester service, a logical architecture could look like this: Listing events are published to a dedicated SNS topic. An SQS queue subscribes to this topic and consumes the events. Here, the events are buffered until a Lambda instance removes them from the queue and processes the corresponding listing. Under normal circumstances -- in which the processing would not involve an atomic operation -- this architecture would be a good fit. It would scale automatically relative to the number of Lambda instances that consume events from the queue, without much additional configuration. However, in the case where we cannot p ## Tiny Letter from Kafka DevFeed: [Tiny Letter from Kafka]() Original publisher: [Read original article]() Published: 2021-10-13T00:00:00Z Content type: article Language: en Sources: [SoundCloud Backstage Blog]() Topics: [Apache-Kafka](), [Event-Streaming](), [Publish-subscribe pattern](), [Messaging](), [Open Source]() Tags: [apache-kafka](), [architecture](), [article](), [distributed](), [engineering](), [event](), [event-streaming](), [kafka](), [messaging](), [open-source](), [streaming]() ### AI overview This article introduces Apache Kafka as an open-source distributed event streaming and messaging platform. It explains the publish-subscribe messaging pattern and uses the story behind Kafka's name to illustrate the system's core flow, with a brief reference to how SoundCloud teams consume event data. ### Source excerpt This article discusses the powerful design choice of Apache Kafka, "an open-source distributed event streaming platform," and gives a sneak... ## Effective batching in streaming dataflow jobs DevFeed: [Effective batching in streaming dataflow jobs]() Original publisher: [Read original article]() Author: Fasih Awan Published: 2019-07-15T11:00:00Z Content type: article Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Streaming](), [Monitoring](), [Publish-subscribe pattern](), [Time Series](), [Google]() Tags: [api](), [batching](), [data](), [data-pipeline](), [engineering](), [metrics](), [monitoring](), [payload](), [payments](), [real-time](), [streaming]() ### AI overview Square describes how it batches payment messages in a Google Dataflow job to produce near-real-time monitoring metrics. The pipeline consumes PubSub messages, applies five-second windows, aggregates payments by dimensions, and sends metrics to SignalFX while accounting for API restrictions. ### Source excerpt How we make near real time monitoring possible ## Scheduling Cloud Functions for Firebase (cron) DevFeed: [Scheduling Cloud Functions for Firebase (cron)]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2019-04-18T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Cloud Functions](), [Firebase CLI](), [SDKs](), [Google](), [Publish-subscribe pattern](), [Command-line interface]() Tags: [cli](), [cloud-functions](), [cloud-pub-sub](), [firebase](), [firebase-cli](), [github](), [launch](), [payment](), [pricing](), [scheduler](), [sdk](), [sdks](), [tutorials](), [updates]() ### AI overview Firebase introduces scheduled Pub/Sub functions built on Cloud Scheduler, allowing developers to schedule Cloud Functions for Firebase using Firebase tools and SDKs. The article covers cron syntax, setup requirements, billing, and costs. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Kafka, a walking skeleton DevFeed: [Kafka, a walking skeleton]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2017-04-29T00:00:00Z Content type: article Language: fr Sources: [The Coffee Workshop]() Topics: [Kafka](), [Open Source](), [Publish-subscribe pattern](), [Hadoop]() Tags: [article](), [blog-post](), [broker](), [kafka](), [messages](), [open-source](), [performance](), [production](), [queuing]() ### AI overview This French article introduces Apache Kafka through a minimal end-to-end implementation, based on Kafka 0.9. It explains Kafka's origins at LinkedIn and describes its performance, durable message retention, scalability, fault resilience, and support for queuing and publish-subscribe messaging. ### Source excerpt Ce blog post est une republication de mon article sur Kafka parut dans le magazine Programmez numéro 196 en mai 2016 (pages 70-73). Il se base sur la version 0.9 de Kafka. ## Can HTTP/2 Replace MQTT? DevFeed: [Can HTTP/2 Replace MQTT?]() Original publisher: [Read original article]() Published: 2015-02-20T00:00:00Z Content type: opinion Language: en Sources: [Tim Kellogg]() Topics: [HTTP](), [MQTT](), [Publish-subscribe pattern](), [client]() Tags: [client](), [http](), [messages](), [mqtt](), [protocol](), [server](), [stream](), [subscription]() ### AI overview The article examines whether HTTP/2 with HPACK could replace MQTT. It explains MQTT's compact headers and publish/subscribe model, then describes how HTTP/2 multiplexing, server push, persistent streams, and headers could approximate MQTT-style messaging. ### Source excerpt Yesterday I got an interesting question: ## Finn.no shares eventHub and Awesome Board repositories on GitHub DevFeed: [Finn.no shares eventHub and Awesome Board repositories on GitHub]() Original publisher: [Read original article]() Author: espen Published: 2011-11-21T19:02:40Z Content type: release Language: en Sources: [Finn.no]() Topics: [GitHub](), [Publish-subscribe pattern](), [jQuery](), [Document Object Model (DOM)](), [App]() Tags: [awesome](), [code](), [event](), [github](), [libraries](), [manipulation](), [repositories](), [tools]() ### AI overview Finn.no announces that it has shared the eventHub and Awesome Board repositories on GitHub under the finn-no organization. eventHub uses the publish-subscribe pattern for loosely coupled components and applications, while Awesome Board supports quality visualization. The shared versions are incomplete compared with the internal version. ### Source excerpt We have finally made an effort to put some of our repos out on GitHub under the finn-no organization. It is not exactly filled with stuff right now, but we aim to put a lot more of our libraries and tools out here. Currently there are a few repositories out there: eventHub Awesome Board[Gone] eventHub This is just a tiny piece of code which enables you to build loosely coupled components or applications by utilizing the publish-subscribe pattern. The eventHub is just an object which publishes event to those to registered event listeners functions. We have written one-page JS applications using only the hub besides jQuery for DOM manipulation. It scales pretty well and it is pretty much what you'd need to create an application. Once your application grows to be quite large you might want to add some other architectural components, but for small to medium sized projects it is brilliant. It is used for the dashboard part for the Awesome Board[Gone]. Awesome Board The Awesome Board[Gone] is the application which has featured in two articles about visualizing quality. We have shown it a few times to different audiences and due to request for making it available we decided it was a good thing to share it on GitHub. There are some pieces missing from the version we run internally, but have patience the rest might still make it to a repo near you. Enjoy! Feel free to drop us a line in the comments section or follow us on Twitter.