5.1 What problem does AdminClient solve?

The concrete motivating case: IoT device topics

"Creating new topics on demand based on user input or data is an especially common use case: IoT apps often receive events from user devices, and write events to topics based on the device type. If the manufacturer produces a new type of device, you either have to remember, via some process, to also create a topic, or the application can dynamically create a new topic if it receives events with an unrecognized device type."

The book is honest about the trade-off: "The second alternative has downsides, but avoiding the dependency on an additional process to generate topics is an attractive feature in the right scenarios."

The "does my topic exist?" problem — and the three bad answers that preceded AdminClient

Your app produces to a specific topic. Before producing the first event, the topic has to exist. Pre-AdminClient, your options were "few... none of them particularly user-friendly":

1. Capture UNKNOWN_TOPIC_OR_PARTITION from producer.send()
   • tell your user they need to create the topic
   • i.e. push the operational burden onto a human, at runtime
2. Hope the cluster has auto.create.topics.enable = true
   • but Ch. 2 says you should set that to false
   • and Ch. 2 notes you can't even check for a topic via the Kafka protocol without creating it
3. Rely on internal APIs
   • “deal with the consequences of no compatibility guarantees”

With AdminClient: "use AdminClient to check whether the topic exists, and if it does not, create it on the spot."

What it covers

"Apache Kafka added the AdminClient in version 0.11 to provide a programmatic API for administrative functionality that was previously done in the command line: listing, creating, and deleting topics; describing the cluster; managing ACLs; and modifying configuration."

This chapter focuses on the three most-used areas: topics, consumer groups, and entity configuration.

---