From 649e0f9b7a1479c37dac8ec08444526d3ab0d772 Mon Sep 17 00:00:00 2001
From: buildmaster
The @Beans can be Function, Consumer or Supplier (all from
java.util), and their parametric types can be String or POJO. A
Function is exposed as a Spring Cloud Stream Processor if
-spring-cloud-function-stream is on the classpath.
-A Consumer is also exposed as a Stream
-Sink and a Supplier translates to a Stream Source.
-HTTP endpoints are exposed if the Stream binder is spring-cloud-stream-binder-servlet.
Functions can be of Flux<String> or Flux<Pojo> and Spring Cloud
-Function takes care of converting the data to and from the desired
-types, as long as it comes in as plain text or (in the case of the
-POJO) JSON. TBD: support for Flux<Message<Pojo>> and maybe plain
-Pojo types (Fluxes implied and implemented by the framework).
Functions can be grouped together in a single application, or deployed
+spring-cloud-function-stream is on the classpath. A Consumer is
+also exposed as a Stream Sink, and a Supplier translates to a
+Stream Source.
Functions can also be of Flux<String> or Flux<Pojo> and Spring
+Cloud Function takes care of converting the data to and from the
+desired types, as long as it comes in as plain text or (in the case of
+the POJO) JSON. There is also support for Message<Pojo> where the
+message headers are copied from the incoming event, depending on the
+adapter. The web adapter also supports conversion from form-encoded
+data to a Map, and if you are using the function with Spring Cloud
+Stream then all the conversion and coercion features for message
+payloads will be applicable as well.
Functions can be grouped together in a single application, or deployed one-per-jar. It’s up to the developer to choose. An app with multiple functions can be deployed multiple times in different "personalities", exposing different functions over different physical transports.