What is the functional programming model in Spring Cloud Stream, and how do you expose a message handler with it?
answer
- Supplier=source, Function=processor, Consumer=sink
- spring.cloud.function.definition names the bean
- bindings <name>-in-0 / <name>-out-0
- plain @Bean, no @StreamListener
- imperative per-message vs Flux once
basics
~20 sYou declare a plain Spring @Bean of type Supplier, Function, or Consumer and name it in the property spring.cloud.function.definition. Spring Cloud Stream wires that bean to the message broker automatically — no special annotations needed.
solid answer
~40 sThe functional model lets you write message handlers as ordinary Java functional beans instead of annotation-driven classes. A Supplier<T> is a source (produces messages), a Function<T,R> is a processor (consumes and produces), and a Consumer<T> is a sink (only consumes). You register one as a @Bean, then list its bean name in spring.cloud.function.definition (e.g. `uppercase`). Spring Cloud Function/Stream discovers it, creates input/output bindings named `<bean>-in-0` and `<bean>-out-0`, and connects those to broker destinations via configuration. This replaced the older @EnableBinding + @StreamListener + interface-channel style, giving cleaner, testable, framework-agnostic code. You can process imperatively (one message at a time) or reactively with Flux types.
code
java · 19 lines@SpringBootApplication
public class DemoApp {
// A processor: consumes a String, produces a String.
// Bean name "uppercase" -> bindings uppercase-in-0 / uppercase-out-0
@Bean
public Function<String, String> uppercase() {
return String::toUpperCase;
}
public static void main(String[] args) {
SpringApplication.run(DemoApp.class, args);
}
}
// application.properties
// spring.cloud.function.definition=uppercase
// spring.cloud.stream.bindings.uppercase-in-0.destination=words
// spring.cloud.stream.bindings.uppercase-out-0.destination=upper-wordsgo deeper
Know the three functional types and that spring.cloud.function.definition activates the bean.
Explain the -in-0/-out-0 binding naming and mapping to destinations, plus imperative vs reactive signatures.
Contrast with the removed annotation model and discuss testability/composition benefits.
Frame it as Spring Cloud Function's FunctionCatalog underpinning SCSt, and reason about auto-discovery fragility and content-type conversion boundaries.
**Spring Cloud Stream (SCSt)** is a framework for building message-driven microservices on top of a broker (Kafka, RabbitMQ, etc.) through a **binder** abstraction, so your code stays broker-agnostic. **The functional model** (introduced in Spring Cloud Stream 3.x, built on **Spring Cloud Function**) replaces the older annotation model. Instead of writing channel interfaces and `@StreamListener` methods, you expose message handlers as ordinary beans of the three `java.util.function` types: - **`Supplier<T>`** — a *source*: takes no input, produces output. Used to originate messages. - **`Function<T,R>`** — a *processor*: consumes `T`, produces `R`. Used for transform-in-the-middle stages. - **`Consumer<T>`** — a *sink*: consumes `T`, returns nothing. Used as a terminal handler. **How activation works.** Declaring the bean is not enough by itself — SCSt only treats it as a stream handler when its bean name appears in the property: ``` spring.cloud.function.definition=uppercase ``` This property (owned by Spring Cloud Function's `FunctionCatalog`) tells the framework which functional bean(s) to expose. For each activated function SCSt derives **bindings**: an input binding `<name>-in-0` (for `Function`/`Consumer`) and an output binding `<name>-out-0` (for `Function`/`Supplier`). The `-0` is the index (first input/output). You then map those bindings to real broker destinations: ``` spring.cloud.stream.bindings.uppercase-in-0.destination=words spring.cloud.stream.bindings.uppercase-out-0.destination=upper-words ``` **Imperative vs reactive.** A `Function<String,String>` is invoked once per message. A `Function<Flux<String>,Flux<String>>` receives the entire inbound stream as a reactive `Flux`, letting you use operators (windowing, buffering, etc.); it's wired once at startup, not per message. **Message vs payload.** You can type the argument as the raw payload (`String`) and let content-type conversion apply, or as `Message<String>` to access headers. **When to use.** This is the current, recommended style for all new SCSt code. The annotation model (`@EnableBinding`, `@StreamListener`, `@Input`/`@Output`) is removed in recent versions. Advantages: functions are plain, unit-testable without the broker, reusable, and composable. **Gotcha.** If you define exactly one functional bean, SCSt can auto-discover it without setting `spring.cloud.function.definition`, but relying on that is fragile — as soon as a second candidate bean exists, discovery becomes ambiguous. Always set the property explicitly in real apps.
- What binding names are generated for a Consumer<T> bean called `audit`?Only an input binding, `audit-in-0`. A Consumer has no return value, so no `-out-0` output binding is created.
- Do you still need the @EnableBinding annotation or a channel interface?No. The functional model removes @EnableBinding, @StreamListener, and @Input/@Output channel interfaces entirely — a plain functional @Bean plus spring.cloud.function.definition is all that's required.
saying these in an interview costs you the question
- Thinking you must annotate the bean with @StreamListener or @EnableBinding
- Believing declaring the bean alone activates it without spring.cloud.function.definition
- Confusing Supplier (source) with Consumer (sink)