From dev-return-95805-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Wed Jul 4 15:42:35 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id EC4CE180608 for ; Wed, 4 Jul 2018 15:42:34 +0200 (CEST) Received: (qmail 67278 invoked by uid 500); 4 Jul 2018 13:42:33 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 67256 invoked by uid 99); 4 Jul 2018 13:42:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2018 13:42:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 9BE7CC00B1 for ; Wed, 4 Jul 2018 13:42:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id tmR92c8KSBqh for ; Wed, 4 Jul 2018 13:42:31 +0000 (UTC) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 589AC5F30E for ; Wed, 4 Jul 2018 13:42:31 +0000 (UTC) Received: by mail-it0-f49.google.com with SMTP id y124-v6so6727569itc.0 for ; Wed, 04 Jul 2018 06:42:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5MpjWAuDLlVOuA/1OcvHdZ+9K238ociTbcgP0ct+jd0=; b=ZWb1Vsclw+EGotm4yR6STzJQ5Z0E/P2bWdixkED1gqIwzU5NEnTLa5HuR4/5ij+hZA h0foO/+irmqg7rnadJP8blbZ+uJ1ybGj49X5jNBf9h+k3jxlb5lJWzO+D5vBoYScjgD9 l3UrsHTp4p2xDoBayLcpW0/ZMneh4sOl+fBHONQelikpAMKevykDuQVHsT08hzmP+9MZ /iMu556MBpPD680EuNWhUnMieO6HwDDJDGiS/o9mjA9YsCeds7APzHrF/Wqt8nTKkKEr QQzPqD5UnORlOQqlvK+8LtSO28YWmG6zV0aWttq6f6+LzzZua6KewICfc7AZnU7E+Uoh IBGw== X-Gm-Message-State: APt69E2MiFQz+sNrPSajain0r1DcMPjl1Bm6ORMwWnDmkBjzanEInDgs maRimrofUm9iPyZrTEb+JdjVwKQ0ObAJhddH2JgQPQ== X-Google-Smtp-Source: AAOMgpdjNUdUeqpsv02bB+jt8RSberlDe6AKyHtpcpc6uwtBiej8Qx1ZArIjUYYtbHKc1g7Dtf5Edg/B39YFfRyFcIU= X-Received: by 2002:a24:dd47:: with SMTP id t68-v6mr1701672itf.29.1530711745202; Wed, 04 Jul 2018 06:42:25 -0700 (PDT) MIME-Version: 1.0 From: Matthias Wessendorf Date: Wed, 4 Jul 2018 15:42:13 +0200 Message-ID: Subject: Builder Pattern for kafka-clients in 2.x ? To: dev@kafka.apache.org Content-Type: multipart/alternative; boundary="000000000000d39c3e05702c996e" --000000000000d39c3e05702c996e Content-Type: text/plain; charset="UTF-8" Hi, I was filing KAFKA-7059 ([1]) and sent a PR adding a new ctor: -- public ProducerRecord(String topic, K key, V value, Iterable
headers) --- One reasonable comment on the PR was instead of doing constructor overloading, why not working on a builder for the ProducerRecord class. I think this is generally a nice idea I was wondering if there is much interest in ? Sample: --- final ProducerRecord myRecord = ProducerRecord.builder() // or an exposed builder .topic("mytopic") .key("Key") .value("the-val") .headers(myHeaderIterable) .build(); --- While at it - instead of just offering a builder for the "ProducerRecord" class, why not adding a builder for the "KafkaProducer" and "KafkaConsumer" clazzes. --- final KafkaProducer myProducer = KafkaProducer.builder() // or an exposed builder clazz .config(myProducerConfig) .keySerializer(myStringSerializer) .valueSerializer(myStringSerializer) .build(); --- to even make the above more nice, I think the "ProducerConfig" (analog the ConsumerConfig) configuration options could be also made accesible w/ this fluent API - instead of properties/map, which is what now dominates the creation of the Consumers/Producers. Any thoughts? If there is interest, I am happy to start a KIP w/ a first draft of the suggested API! Cheers, Matthias [1] https://issues.apache.org/jira/browse/KAFKA-7059 -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf --000000000000d39c3e05702c996e--