sarama VS kafka-go

Note: Since there are multiple Go clients for Kafka (including Sarama), please make sure to consult their client documentation to confirm whether they support IAM authentication.

You might want to gradually replace that one with https://github.com/twmb/franz-go because Shopify is looking to find a new owner for Sarama and, until or if they do, it seems to be falling behind with maintenance: https://github.com/Shopify/sarama/issues/2461 For example, they still haven’t addressed this breaking change https://github.com/Shopify/sarama/issues/2358. franz-go has worked well so far in Benthos https://github.com/benthosdev/benthos/tree/main/internal/impl/kafka and it will likely end up as the only implementation once the Sarama-based one will be deprecated

I've used mainly sarama wrapped with a bit of bespoke helper libraries. Never really looked into others, just grabbed one that was actively maintained and went for it.

Well, as someone who reviews a lot of code, I don't like seeing 100s of little files when a handful of logically grouped files would do. For example, this popular go project: https://github.com/Shopify/sarama is currently 256 small .go files, largely following a one class/file rule.

The first example is something we ran into while working on a project. Up until recently, the sarama library (Go library for Apache Kafka) contained the following piece of code (at sarama/version.go):

Im using the go sarama library to connect to the cluster, using this basic example.

If you find the kafka input slow, try kafka_franz. It might be a bit faster, since it’s based on https://github.com/twmb/franz-go. The kafka one is based on https://github.com/Shopify/sarama. You can also write a custom input based on https://github.com/confluentinc/confluent-kafka-go, but this library relies on CGo, which can be annoying.

There are a few factors that are stopping me from using kafka-go over Shopify's sarama.

There are two main libraries that people use to write clients Confluent Kafka and segment io kafka

Unlike the standard scripts, and many binary clients, it's a native, statically-compiled, binary. It uses segmentio/go-kafka internally, which means CGO can be disabled during compilation.

Scaling up our producers/consumers proved to be more cost-effective than adding more CPU/brokers to the Kafka cluster. To accomplish this, we used the segmentio/kafka-go client library which provides an excellent abstraction for interacting with the cluster and will handle data compression completely transparently.

PostgeSQL as event store database Kafka as messages broker gRPC Go implementation of gRPC Jaeger open source, end-to-end distributed tracing Prometheus monitoring and alerting Grafana for to compose observability dashboards with everything from Prometheus MongoDB MongoDB database Elasticsearch Elasticsearch client for Go. Echo web framework Kibana Kibana is data visualization dashboard software for Elasticsearch Migrate for migrations

I want to announce the first release of a kafkagosaur, a new Kafka client. It's built using WebAssembly and binds to the kafka-go library. The first release includes functionality to read and write Kafka messages and SASL support.

Use the Segment Kafka library, not Sarama, it’s much easier to use https://github.com/segmentio/kafka-go

Kafaka - kafka-go, Debezium Outbox

Segment learned quite some time ago that librdkafka-go has problems like these (and doesn’t support Contexts either), so they wrote a pure Go replacement instead. https://github.com/segmentio/kafka-go

In this article let's try to create closer to real world CQRS microservices with tracing and monitoring using: 🚀 Kafka as messages broker gRPC Go implementation of gRPC PostgreSQL as database Jaeger open source, end-to-end distributed tracing Prometheus monitoring and alerting Grafana for to compose observability dashboards with everything from Prometheus MongoDB Web and API based SMTP testing Redis Type-safe Redis client for Golang swag Swagger for Go Echo web framework