NSQ vs gRPC

Overview

NSQ

Stacks142

Followers356

Votes148

gRPC

Stacks2.4K

Followers1.4K

Votes64

GitHub Stars43.9K

Forks11.0K

NSQ vs gRPC: What are the differences?

Introduction

NSQ and gRPC are both popular technologies used in building distributed systems. However, there are some key differences between NSQ and gRPC that developers should be aware of. In this article, we will explore six key differences between NSQ and gRPC.

Messaging vs Remote Procedure Call: NSQ is primarily a messaging system, designed to handle the reliable delivery of messages between distributed components. It provides features like pub-sub messaging, message queues, and fault-tolerant message delivery. On the other hand, gRPC is a framework for building remote procedure call (RPC) systems. It enables communication between services by allowing them to invoke methods on remote services as if they were local.
Transport Protocol: NSQ uses its custom TCP-based protocol for communication between publishers and subscribers. It handles message delivery, routing, and load balancing. In contrast, gRPC uses HTTP/2 as its transport protocol. HTTP/2 provides features like multiplexed streams, flow control, and header compression, making gRPC efficient for high-performance communication.
Serialization: NSQ typically uses JSON or binary serialization for the messages it carries. It offers flexibility in terms of the payload format, but JSON serialization introduces higher overhead. On the other hand, gRPC uses Protocol Buffers as the default serialization mechanism. Protocol Buffers are a language-agnostic, efficient, and extensible serialization format that provides smaller message sizes and faster serialization/deserialization.
Service Definition: NSQ does not enforce a specific contract or service definition. It allows publishers and subscribers to define their own message formats and publish/subscribe to those topics. In comparison, gRPC uses Protocol Buffers to define a service interface and the payload of request/response messages. This strong typing and service contract enable better code generation, documentation, and inter-service communication.
Language Support: NSQ has client libraries available in various programming languages like Go, Java, Python, and Ruby. It provides flexibility to choose the language of choice for building NSQ producers and consumers. On the other hand, gRPC offers broader language support with client libraries available in many languages, including Go, Java, Python, Ruby, C++, C#, and more. This wide language support makes gRPC suitable for polyglot microservices architectures.
Error Handling: NSQ has a built-in retry mechanism for failed messages, allowing publishers to control the retry behavior. It also has built-in support for message timeouts and requeuing. In contrast, gRPC relies on the underlying HTTP/2 protocol's status codes and headers for error handling. It provides facilities like status codes, trailers, and metadata for handling errors in a more standardized manner.

In Summary, NSQ is a messaging system primarily used for reliable message delivery, while gRPC is a framework for building RPC systems. NSQ uses a custom TCP-based protocol, supports flexible message formats, and offers language libraries in various programming languages. On the other hand, gRPC uses HTTP/2 as its transport protocol, leverages Protocol Buffers for efficient serialization, enforces strong service contracts, provides broader language support, and relies on HTTP/2 error handling mechanisms.

Share your Stack

Help developers discover the tools you use. Get visibility for your team's tech choices and contribute to the community's knowledge.

View Docs

CLI (Node.js)

Manual

Advice on NSQ, gRPC

Pramod

Co Founder at Usability Designs

Mar 2, 2020

Needs advice

I am looking into IoT World Solution where we have MQTT Broker. This MQTT Broker Sits in one of the Data Center. We are doing a lot of Alert and Alarm related processing on that Data, Currently, we are looking into Solution which can do distributed persistence of log/alert primarily on remote Disk.

Our primary need is to use lightweight where operational complexity and maintenance costs can be significantly reduced. We want to do it on-premise so we are not considering cloud solutions.

We looked into the following alternatives:

Apache Kafka - Great choice but operation and maintenance wise very complex. Rabbit MQ - High availability is the issue, Apache Pulsar - Operational Complexity. NATS - Absence of persistence. Akka Streams - Big learning curve and operational streams.

So we are looking into a lightweight library that can do distributed persistence preferably with publisher and subscriber model. Preferable on JVM stack.

572k views572k

Comments

Detailed Comparison

NSQ	gRPC
NSQ is a realtime distributed messaging platform designed to operate at scale, handling billions of messages per day. It promotes distributed and decentralized topologies without single points of failure, enabling fault tolerance and high availability coupled with a reliable message delivery guarantee. See features & guarantees.	gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking...
support distributed topologies with no SPOF;horizontally scalable (no brokers, seamlessly add more nodes to the cluster);low-latency push based message delivery (performance);combination load-balanced and multicast style message routing;excel at both streaming (high-throughput) and job oriented (low-throughput) workloads;primarily in-memory (beyond a high-water mark messages are transparently kept on disk);runtime discovery service for consumers to find producers (nsqlookupd);transport layer security (TLS);data format agnostic;few dependencies (easy to deploy) and a sane, bounded, default configuration;simple TCP protocol supporting client libraries in any language;HTTP interface for stats, admin actions, and producers (no client library needed to publish);integrates with statsd for realtime instrumentation;robust cluster administration interface (nsqadmin)	Simple service definition;Works across languages and platforms;Start quickly and scale;Works across languages and platforms;Bi-directional streaming and integrated auth
Statistics
GitHub Stars -	GitHub Stars 43.9K
GitHub Forks -	GitHub Forks 11.0K
Stacks 142	Stacks 2.4K
Followers 356	Followers 1.4K
Votes 148	Votes 64
Pros & Cons
Pros 29 It's in golang 20 Distributed 20 Lightweight 18 Easy setup 17 High throughput Cons 1 Get NSQ behavior out of Kafka but not inverse 1 Long term persistence 1 HA	Pros 25 Higth performance 15 The future of API 13 Easy setup 5 Contract-based 4 Polyglot
Integrations
No integrations available	.NET Swift Java JavaScript C++ Kotlin

What are some alternatives to NSQ, gRPC?

Kafka

Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.

RabbitMQ

RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.

Celery

Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well.

Amazon SQS

Transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available. With SQS, you can offload the administrative burden of operating and scaling a highly available messaging cluster, while paying a low price for only what you use.

ActiveMQ

Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License.

ZeroMQ

The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialised messaging middleware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more.

Apache NiFi

An easy to use, powerful, and reliable system to process and distribute data. It supports powerful and scalable directed graphs of data routing, transformation, and system mediation logic.

Gearman

Gearman allows you to do work in parallel, to load balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events.

Memphis

Highly scalable and effortless data streaming platform. Made to enable developers and data teams to collaborate and build real-time and streaming apps fast.

IronMQ

An easy-to-use highly available message queuing service. Built for distributed cloud applications with critical messaging needs. Provides on-demand message queuing with advanced features and cloud-optimized performance.

Related Comparisons

NSQ vs gRPC: What are the differences?

Introduction

Messaging vs Remote Procedure Call: NSQ is primarily a messaging system, designed to handle the reliable delivery of messages between distributed components. It provides features like pub-sub messaging, message queues, and fault-tolerant message delivery. On the other hand, gRPC is a framework for building remote procedure call (RPC) systems. It enables communication between services by allowing them to invoke methods on remote services as if they were local.
Transport Protocol: NSQ uses its custom TCP-based protocol for communication between publishers and subscribers. It handles message delivery, routing, and load balancing. In contrast, gRPC uses HTTP/2 as its transport protocol. HTTP/2 provides features like multiplexed streams, flow control, and header compression, making gRPC efficient for high-performance communication.
Serialization: NSQ typically uses JSON or binary serialization for the messages it carries. It offers flexibility in terms of the payload format, but JSON serialization introduces higher overhead. On the other hand, gRPC uses Protocol Buffers as the default serialization mechanism. Protocol Buffers are a language-agnostic, efficient, and extensible serialization format that provides smaller message sizes and faster serialization/deserialization.
Service Definition: NSQ does not enforce a specific contract or service definition. It allows publishers and subscribers to define their own message formats and publish/subscribe to those topics. In comparison, gRPC uses Protocol Buffers to define a service interface and the payload of request/response messages. This strong typing and service contract enable better code generation, documentation, and inter-service communication.
Language Support: NSQ has client libraries available in various programming languages like Go, Java, Python, and Ruby. It provides flexibility to choose the language of choice for building NSQ producers and consumers. On the other hand, gRPC offers broader language support with client libraries available in many languages, including Go, Java, Python, Ruby, C++, C#, and more. This wide language support makes gRPC suitable for polyglot microservices architectures.
Error Handling: NSQ has a built-in retry mechanism for failed messages, allowing publishers to control the retry behavior. It also has built-in support for message timeouts and requeuing. In contrast, gRPC relies on the underlying HTTP/2 protocol's status codes and headers for error handling. It provides facilities like status codes, trailers, and metadata for handling errors in a more standardized manner.

NSQ vs gRPC

Overview