Stories with Tag pubsub

• Socketcluster: Highly scalable pub/sub and RPC SDK

  permalink

  Posted: 2025-04-14 15:45:45

  Verbose tl;dr

  SocketCluster is a real-time framework built on top of Engine.IO and Socket.IO, designed for highly scalable, multi-process, and multi-machine WebSocket communication. It offers a simple pub/sub API for broadcasting data to multiple clients and an RPC framework for calling procedures remotely across processes or servers. SocketCluster emphasizes ease of use, scalability, and fault tolerance, enabling developers to build real-time applications like chat apps, collaborative editing tools, and multiplayer games with minimal effort. It features automatic client reconnect, horizontal scalability, and a built-in publish/subscribe system, making it suitable for complex, demanding real-time application development.

  SocketCluster is presented as a highly scalable, real-time communication framework built on top of Engine.IO and designed for building robust, performant, and feature-rich applications that require real-time interaction. It offers both publish/subscribe (pub/sub) and remote procedure call (RPC) functionalities, providing developers with flexibility in designing their communication flows.

  The framework emphasizes horizontal scalability, allowing applications to handle a growing number of connections and messages by distributing the load across multiple CPU cores and servers. This distributed architecture is facilitated by a central message broker, referred to as a "broker," that acts as a hub for routing messages between different server instances and clients. SocketCluster clients can seamlessly connect to any available server in the cluster, and messages published on one server are automatically propagated to all subscribed clients across all servers.

  SocketCluster's pub/sub system allows clients to subscribe to named channels and receive messages broadcast on those channels. This facilitates efficient one-to-many and many-to-many communication patterns, enabling applications like chat rooms, live notifications, and collaborative editing. The RPC mechanism provides a structured way for clients to invoke remote functions on the server and receive responses, similar to traditional client-server communication. This is suitable for tasks like data fetching, user authentication, and other request-response interactions.

  The framework also features middleware support, allowing developers to intercept and modify messages at various stages of the communication pipeline. This is useful for implementing authentication, authorization, logging, and other cross-cutting concerns. Furthermore, SocketCluster provides built-in support for multiple channels and channel namespaces, allowing for granular control over message routing and access control.

  Beyond the core communication features, SocketCluster offers a comprehensive suite of tools and utilities for building real-time applications. These include features for presence tracking (knowing which users are online and in which channels), server-side data storage via an integrated data layer called SCC, and the ability to publish raw events for custom communication needs. The SDK is designed to be developer-friendly, offering a straightforward API and comprehensive documentation. Its open-source nature allows developers to inspect, customize, and contribute to its development. Finally, SocketCluster supports both client-side (browser-based) and server-side (Node.js) environments, enabling developers to build full-stack real-time applications with a consistent programming model.

  • socketcluster
  • realtime
  • pubsub
  • publish-subscribe
  • rpc
  • remote procedure call
  • SDK
  • scalability
  • High Availability
  • javascript
  • nodejs
  • websocket
  • networking
  • Communication
  • Messaging
  • Server
  • Client
  • Library
  • open-source

  Summary of Comments ( 1 )
  https://news.ycombinator.com/item?id=43682615

  Verbose tl;dr

  HN commenters generally expressed skepticism about SocketCluster's claims of scalability and performance advantages. Several users questioned the project's activity level and lack of recent updates, pointing to a potentially stalled or abandoned state. Some compared it unfavorably to established alternatives like Redis Pub/Sub and Kafka, citing their superior maturity and wider community support. The lack of clear benchmarks or performance data to substantiate SocketCluster's claims was also a common criticism. While the author engaged with some of the comments, defending the project's viability, the overall sentiment leaned towards caution and doubt regarding its practical benefits.

  The Hacker News post for Socketcluster: Highly scalable pub/sub and RPC SDK (https://news.ycombinator.com/item?id=43682615) has a moderate number of comments, exploring various aspects of the technology and its comparison to alternatives.

  Several commenters discuss the complexity and potential overhead introduced by SocketCluster compared to simpler alternatives like Redis pub/sub. One commenter points out that using Redis, potentially combined with a simple message queue, might be a more straightforward solution for many use cases. This sparks a discussion about the trade-offs between a full-featured framework like SocketCluster and a more DIY approach with simpler components. The original poster (OP), the creator of SocketCluster, engages in this discussion, highlighting the benefits of SocketCluster's built-in features such as horizontal scaling and client-side libraries. They argue that while a simpler setup might suffice for small projects, SocketCluster shines when dealing with complex, large-scale applications.

  Another thread of discussion revolves around the specific use cases where SocketCluster might be advantageous. Commenters explore scenarios involving real-time updates, collaborative applications, and the need for robust client-server communication. The OP provides examples and elaborates on how SocketCluster's architecture addresses the challenges of these use cases, emphasizing its ability to handle high concurrency and maintain stateful connections.

  A few comments touch upon the maturity and adoption of SocketCluster. While some express interest in the technology, others raise concerns about the relatively smaller community and the potential learning curve associated with a less mainstream solution. The OP addresses these concerns by pointing to existing documentation and resources, and by reiterating the framework's active development and responsiveness to community feedback.

  Finally, some comments delve into technical details, such as the choice of underlying technologies used by SocketCluster and its performance characteristics. The OP participates in these discussions, providing insights into the design decisions and offering comparisons to alternative solutions. They also highlight the open-source nature of the project and encourage community contributions.

  Overall, the comments provide a balanced perspective on SocketCluster, acknowledging its potential while also acknowledging the trade-offs involved. They offer valuable insights into the specific use cases where it might be a good fit, and provide a platform for a constructive discussion about its strengths and weaknesses compared to other solutions.

• Show HN: JavaScript PubSub in 163 Bytes

  permalink

  Posted: 2025-03-31 01:37:55

  Verbose tl;dr

  This project presents a tiny JavaScript PubSub implementation weighing in at a mere 163 bytes. It provides basic publish and subscribe functionality, allowing developers to broadcast messages on specific topics (strings) and have subscribed functions execute when those topics are published to. The library focuses on extreme minimalism, sacrificing features like wildcard subscriptions or complex message filtering for an incredibly small footprint. This makes it suitable for resource-constrained environments or situations where a full-fledged PubSub library would be overkill.

  Hassan Shaikley has introduced a remarkably compact implementation of the Publish-Subscribe (PubSub) messaging pattern in JavaScript, clocking in at a mere 163 bytes. This minimalist library, dubbed "pico-pubsub," provides a lightweight solution for enabling communication between different parts of a JavaScript application without requiring direct coupling. It achieves this by allowing components to "subscribe" to specific "topics" or channels. When a message is "published" to a given topic, all subscribers to that topic receive a notification, along with the published data.

  The library exposes two primary functions: sub for subscribing and pub for publishing. The sub function takes two arguments: the topic name (a string) and a callback function that will be executed when a message is published to that topic. This callback function receives the published data as its argument. The pub function also takes two arguments: the topic name and the data to be published. Upon invocation, pub will trigger the execution of all callback functions associated with the specified topic, passing the provided data to each. This mechanism facilitates asynchronous communication and decouples publishers from subscribers, allowing for greater flexibility and modularity in application design. Shaikley's focus on minimizing the code size makes this implementation particularly attractive for resource-constrained environments or situations where a full-fledged messaging library would be overkill. The compact nature of the code also makes it relatively easy to understand and integrate into existing projects.

  • javascript
  • pubsub
  • Library
  • lightweight
  • small
  • Minimal
  • codegolf
  • bytes
  • Show HN
  • GitHub
  • opensource
  • event handling
  • Messaging

  Summary of Comments ( 20 )
  https://news.ycombinator.com/item?id=43529774

  Verbose tl;dr

  Hacker News users discussed the minimalist JavaScript pub/sub implementation, praising its small size and cleverness. Some questioned its practicality for complex applications, suggesting larger libraries like mitt might be more suitable due to features like wildcard subscriptions and unsubscribing. Others debated the value of minimizing bundle size in modern web development, with some arguing that 163 bytes is a negligible saving. A few commenters suggested improvements or alternative implementations, including using a Map instead of an object for storing subscriptions to avoid prototype pollution issues. Overall, the reception was positive, though tinged with pragmatic considerations regarding real-world usage.

  The Hacker News post discussing the 163-byte JavaScript PubSub implementation has generated several comments, primarily focusing on the code's size, efficiency, and practicality.

  One commenter questions the value of such a minimal implementation, arguing that the small size comes at the cost of features and robustness found in more established PubSub libraries. They suggest that using a slightly larger, but more feature-rich library would likely be a better choice in real-world applications. This commenter also raises the point that minification often obscures the actual usefulness and readability of the code, implying that the 163-byte size is less significant than it appears.

  Another comment chain discusses the potential drawbacks of using a single global event bus, highlighting the possibility of naming collisions and the difficulty of managing subscriptions in larger applications. They advocate for more structured approaches, such as namespacing or using a library that provides better organization.

  One commenter focuses on the potential performance implications, specifically the use of eval() for executing the subscriber functions. They raise concerns about the security and efficiency implications of using eval() and propose alternative methods that could be more performant and secure.

  Further discussion revolves around alternative small PubSub implementations, with users sharing links to similar projects and comparing their sizes and features. Some commenters appreciate the minimalist approach and see the code as an interesting demonstration of how concise JavaScript can be. They acknowledge that while it may not be suitable for complex applications, it could be useful for smaller projects or educational purposes.

  A few comments dive into the specific code details, suggesting potential optimizations or pointing out potential issues. For example, one comment mentions the use of the this keyword inside the subscriber functions, which might not behave as expected depending on the calling context.

  Overall, the comments represent a mixture of perspectives, with some praising the brevity of the code while others question its practicality and raise concerns about potential issues. The discussion highlights the trade-offs involved in prioritizing code size over features and maintainability, ultimately suggesting that the choice of a PubSub implementation depends heavily on the specific needs of the project.