$ curl localhost:8080 -d foo
-FOO
-diff --git a/reference/html/functional.html b/reference/html/functional.html index 2f7c5ffa0..f5d172d4b 100644 --- a/reference/html/functional.html +++ b/reference/html/functional.html @@ -96,8 +96,8 @@ $(addBlockSwitches);
You can run the above in a serverless platform, like AWS Lambda or Azure Functions, or you can run it in its own HTTP server just by including spring-cloud-starter-function-web on the classpath. Running the main method would expose an endpoint that you can use to ping that uppercase function:
$ curl localhost:8080 -d foo
-FOO
-The web adapter in spring-cloud-starter-function-web uses Spring MVC, so you needed a Servlet container. You can also use Webflux where the default server is netty (even though you can still use Servlet containers if you want to) - just include the spring-cloud-starter-function-webflux dependency instead. The functionality is the same, and the user application code can be used in both.
Now for the functional beans: the user application code can be recast into "functional" form, like this:
The business logic beans that you register in a Spring Cloud Function app are of type FunctionRegistration. This is a wrapper that contains both the function and information about the input and output types. In the @Bean form of the application that information can be derived reflectively, but in a functional bean registration some of it is lost unless we use a FunctionRegistration.
The business logic beans that you register in a Spring Cloud Function app are of type FunctionRegistration.
+This is a wrapper that contains both the function and information about the input and output types. In the @Bean
+form of the application that information can be derived reflectively, but in a functional bean registration some of
+it is lost unless we use a FunctionRegistration.
An alternative to using an ApplicationContextInitializer and FunctionRegistration is to make the application itself implement Function (or Consumer or Supplier). Example (equivalent to the above):
An alternative to using an ApplicationContextInitializer and FunctionRegistration is to make the application
+itself implement Function (or Consumer or Supplier). Example (equivalent to the above):
It would also work if you add a separate, standalone class of type Function and register it with the SpringApplication using an alternative form of the run() method. The main thing is that the generic type information is available at runtime through the class declaration.
It would also work if you add a separate, standalone class of type Function and register it with
+the SpringApplication using an alternative form of the run() method. The main thing is that the generic
+type information is available at runtime through the class declaration.
The app runs in its own HTTP server if you add spring-cloud-starter-function-webflux (it won’t work with the MVC starter at the moment because the functional form of the embedded Servlet container hasn’t been implemented). The app also runs just fine in AWS Lambda or Azure Functions, and the improvements in startup time are dramatic.
| - - | -
-The "lite" web server has some limitations for the range of Function signatures - in particular it doesn’t (yet) support Message input and output, but POJOs and any kind of Publisher should be fine.
- |
-
Spring Cloud Function also has some utilities for integration testing that will be very familiar to Spring Boot users. For example, here is an integration test for the HTTP server wrapping the app above:
+Suppose you have
@RunWith(SpringRunner.class)
-@FunctionalSpringBootTest
-@AutoConfigureWebTestClient
-public class FunctionalTests {
-
- @Autowired
- private WebTestClient client;
-
- @Test
- public void words() throws Exception {
- client.post().uri("/").body(Mono.just("foo"), String.class).exchange()
- .expectStatus().isOk().expectBody(String.class).isEqualTo("FOO");
+@Component
+public class CustomFunction implements Function<Flux<Foo>, Flux<Bar>> {
+ @Override
+ public Flux<Bar> apply(Flux<Foo> flux) {
+ return flux.map(foo -> new Bar("This is a Bar object from Foo value: " + foo.getValue()));
}
}
This test is almost identical to the one you would write for the @Bean version of the same app - the only difference is the @FunctionalSpringBootTest annotation, instead of the regular @SpringBootTest. All the other pieces, like the @Autowired WebTestClient, are standard Spring Boot features.
You register it as such:
+@Override
+public void initialize(GenericApplicationContext context) {
+ context.registerBean("function", FunctionRegistration.class,
+ () -> new FunctionRegistration<>(new CustomFunction()).type(CustomFunction.class));
+}
+Most Spring Cloud Function apps have a relatively small scope compared to the whole of Spring Boot,
+so we are able to adapt it to these functional bean definitions easily. If you step outside that limited scope,
+you can extend your Spring Cloud Function app by switching back to @Bean style configuration, or by using a hybrid
+approach. If you want to take advantage of Spring Boot autoconfiguration for integrations with external datastores,
+for example, you will need to use @EnableAutoConfiguration. Your functions can still be defined using the functional
+declarations if you want (i.e. the "hybrid" style), but in that case you will need to explicitly switch off the "full
+functional mode" using spring.functional.enabled=false so that Spring Boot can take back control.
Spring Cloud Function also has some utilities for integration testing that will be very familiar to Spring Boot users.
+Suppose this is your application:
+@SpringBootApplication
+public class SampleFunctionApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(SampleFunctionApplication.class, args);
+ }
+
+ @Bean
+ public Function<String, String> uppercase() {
+ return v -> v.toUpperCase();
+ }
+}
+Here is an integration test for the HTTP server wrapping this application:
+@SpringBootTest(classes = SampleFunctionApplication.class,
+ webEnvironment = WebEnvironment.RANDOM_PORT)
+public class WebFunctionTests {
+
+ @Autowired
+ private TestRestTemplate rest;
+
+ @Test
+ public void test() throws Exception {
+ ResponseEntity<String> result = this.rest.exchange(
+ RequestEntity.post(new URI("/uppercase")).body("hello"), String.class);
+ System.out.println(result.getBody());
+ }
+}
+or when function bean definition style is used:
+@FunctionalSpringBootTest
+public class WebFunctionTests {
+
+ @Autowired
+ private TestRestTemplate rest;
+
+ @Test
+ public void test() throws Exception {
+ ResponseEntity<String> result = this.rest.exchange(
+ RequestEntity.post(new URI("/uppercase")).body("hello"), String.class);
+ System.out.println(result.getBody());
+ }
+}
+This test is almost identical to the one you would write for the @Bean version of the same app - the only difference
+is the @FunctionalSpringBootTest annotation, instead of the regular @SpringBootTest. All the other pieces,
+like the @Autowired TestRestTemplate, are standard Spring Boot features.
And to help with correct dependencies here is the excerpt from POM
+ <parent>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-parent</artifactId>
+ <version>2.2.2.RELEASE</version>
+ <relativePath/> <!-- lookup parent from repository -->
+ </parent>
+ . . . .
+ <dependency>
+ <groupId>org.springframework.cloud</groupId>
+ <artifactId>spring-cloud-function-web</artifactId>
+ <version>3.0.1.BUILD-SNAPSHOT</version>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter</artifactId>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-web</artifactId>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-test</artifactId>
+ <scope>test</scope>
+ <exclusions>
+ <exclusion>
+ <groupId>org.junit.vintage</groupId>
+ <artifactId>junit-vintage-engine</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+Or you could write a test for a non-HTTP app using just the FunctionCatalog. For example:
(The FunctionCatalog always returns functions from Flux to Flux, even if the user declares them with a simpler signature.)
Most Spring Cloud Function apps have a relatively small scope compared to the whole of Spring Boot, so we are able to adapt it to these functional bean definitions easily. If you step outside that limited scope, you can extend your Spring Cloud Function app by switching back to @Bean style configuration, or by using a hybrid approach. If you want to take advantage of Spring Boot autoconfiguration for integrations with external datastores, for example, you will need to use @EnableAutoConfiguration. Your functions can still be defined using the functional declarations if you want (i.e. the "hybrid" style), but in that case you will need to explicitly switch off the "full functional mode" using spring.functional.enabled=false so that Spring Boot can take back control.
For cases where there is more then a single function in catalog and you want to map a specific function to the root
path (e.g., "/"), or you want to compose several functions and then map to the root path you can do so by providing
-spring.cloud.function.definition property which essentially used by spring-=cloud-function-web module to provide
+spring.cloud.function.definition property which essentially used by spring-cloud-function-web module to provide
default mapping for cases where there is some type of a conflict (e.g., more then one function available etc).
When POSTing text the response format might be different with Spring Boot 2.0 and older versions, depending on the content negotiation (provide content type and accpt headers for the best results).
See Testing Functional Applications to see the details and example on how to test such application.
+To send or receive messages from a broker (such as RabbitMQ or Kafka) you can leverage spring-cloud-stream project and it’s integration with Spring Cloud Function.
-Please refer to Spring Cloud Function section of the Spring Cloud Stream reference manual for more details and examples.
You can run the above in a serverless platform, like AWS Lambda or Azure Functions, or you can run it in its own HTTP server just by including spring-cloud-starter-function-web on the classpath. Running the main method would expose an endpoint that you can use to ping that uppercase function:
$ curl localhost:8080 -d foo
-FOO
-The web adapter in spring-cloud-starter-function-web uses Spring MVC, so you needed a Servlet container. You can also use Webflux where the default server is netty (even though you can still use Servlet containers if you want to) - just include the spring-cloud-starter-function-webflux dependency instead. The functionality is the same, and the user application code can be used in both.
Now for the functional beans: the user application code can be recast into "functional" form, like this:
The business logic beans that you register in a Spring Cloud Function app are of type FunctionRegistration. This is a wrapper that contains both the function and information about the input and output types. In the @Bean form of the application that information can be derived reflectively, but in a functional bean registration some of it is lost unless we use a FunctionRegistration.
The business logic beans that you register in a Spring Cloud Function app are of type FunctionRegistration.
+This is a wrapper that contains both the function and information about the input and output types. In the @Bean
+form of the application that information can be derived reflectively, but in a functional bean registration some of
+it is lost unless we use a FunctionRegistration.
An alternative to using an ApplicationContextInitializer and FunctionRegistration is to make the application itself implement Function (or Consumer or Supplier). Example (equivalent to the above):
An alternative to using an ApplicationContextInitializer and FunctionRegistration is to make the application
+itself implement Function (or Consumer or Supplier). Example (equivalent to the above):
It would also work if you add a separate, standalone class of type Function and register it with the SpringApplication using an alternative form of the run() method. The main thing is that the generic type information is available at runtime through the class declaration.
It would also work if you add a separate, standalone class of type Function and register it with
+the SpringApplication using an alternative form of the run() method. The main thing is that the generic
+type information is available at runtime through the class declaration.
The app runs in its own HTTP server if you add spring-cloud-starter-function-webflux (it won’t work with the MVC starter at the moment because the functional form of the embedded Servlet container hasn’t been implemented). The app also runs just fine in AWS Lambda or Azure Functions, and the improvements in startup time are dramatic.
| - - | -
-The "lite" web server has some limitations for the range of Function signatures - in particular it doesn’t (yet) support Message input and output, but POJOs and any kind of Publisher should be fine.
- |
-
Spring Cloud Function also has some utilities for integration testing that will be very familiar to Spring Boot users. For example, here is an integration test for the HTTP server wrapping the app above:
+Suppose you have
@RunWith(SpringRunner.class)
-@FunctionalSpringBootTest
-@AutoConfigureWebTestClient
-public class FunctionalTests {
-
- @Autowired
- private WebTestClient client;
-
- @Test
- public void words() throws Exception {
- client.post().uri("/").body(Mono.just("foo"), String.class).exchange()
- .expectStatus().isOk().expectBody(String.class).isEqualTo("FOO");
+@Component
+public class CustomFunction implements Function<Flux<Foo>, Flux<Bar>> {
+ @Override
+ public Flux<Bar> apply(Flux<Foo> flux) {
+ return flux.map(foo -> new Bar("This is a Bar object from Foo value: " + foo.getValue()));
}
}
This test is almost identical to the one you would write for the @Bean version of the same app - the only difference is the @FunctionalSpringBootTest annotation, instead of the regular @SpringBootTest. All the other pieces, like the @Autowired WebTestClient, are standard Spring Boot features.
You register it as such:
+@Override
+public void initialize(GenericApplicationContext context) {
+ context.registerBean("function", FunctionRegistration.class,
+ () -> new FunctionRegistration<>(new CustomFunction()).type(CustomFunction.class));
+}
+Most Spring Cloud Function apps have a relatively small scope compared to the whole of Spring Boot,
+so we are able to adapt it to these functional bean definitions easily. If you step outside that limited scope,
+you can extend your Spring Cloud Function app by switching back to @Bean style configuration, or by using a hybrid
+approach. If you want to take advantage of Spring Boot autoconfiguration for integrations with external datastores,
+for example, you will need to use @EnableAutoConfiguration. Your functions can still be defined using the functional
+declarations if you want (i.e. the "hybrid" style), but in that case you will need to explicitly switch off the "full
+functional mode" using spring.functional.enabled=false so that Spring Boot can take back control.
Spring Cloud Function also has some utilities for integration testing that will be very familiar to Spring Boot users.
+Suppose this is your application:
+@SpringBootApplication
+public class SampleFunctionApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(SampleFunctionApplication.class, args);
+ }
+
+ @Bean
+ public Function<String, String> uppercase() {
+ return v -> v.toUpperCase();
+ }
+}
+Here is an integration test for the HTTP server wrapping this application:
+@SpringBootTest(classes = SampleFunctionApplication.class,
+ webEnvironment = WebEnvironment.RANDOM_PORT)
+public class WebFunctionTests {
+
+ @Autowired
+ private TestRestTemplate rest;
+
+ @Test
+ public void test() throws Exception {
+ ResponseEntity<String> result = this.rest.exchange(
+ RequestEntity.post(new URI("/uppercase")).body("hello"), String.class);
+ System.out.println(result.getBody());
+ }
+}
+or when function bean definition style is used:
+@FunctionalSpringBootTest
+public class WebFunctionTests {
+
+ @Autowired
+ private TestRestTemplate rest;
+
+ @Test
+ public void test() throws Exception {
+ ResponseEntity<String> result = this.rest.exchange(
+ RequestEntity.post(new URI("/uppercase")).body("hello"), String.class);
+ System.out.println(result.getBody());
+ }
+}
+This test is almost identical to the one you would write for the @Bean version of the same app - the only difference
+is the @FunctionalSpringBootTest annotation, instead of the regular @SpringBootTest. All the other pieces,
+like the @Autowired TestRestTemplate, are standard Spring Boot features.
And to help with correct dependencies here is the excerpt from POM
+ <parent>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-parent</artifactId>
+ <version>2.2.2.RELEASE</version>
+ <relativePath/> <!-- lookup parent from repository -->
+ </parent>
+ . . . .
+ <dependency>
+ <groupId>org.springframework.cloud</groupId>
+ <artifactId>spring-cloud-function-web</artifactId>
+ <version>3.0.1.BUILD-SNAPSHOT</version>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter</artifactId>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-web</artifactId>
+ <scope>test</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-test</artifactId>
+ <scope>test</scope>
+ <exclusions>
+ <exclusion>
+ <groupId>org.junit.vintage</groupId>
+ <artifactId>junit-vintage-engine</artifactId>
+ </exclusion>
+ </exclusions>
+ </dependency>
+Or you could write a test for a non-HTTP app using just the FunctionCatalog. For example:
(The FunctionCatalog always returns functions from Flux to Flux, even if the user declares them with a simpler signature.)
Most Spring Cloud Function apps have a relatively small scope compared to the whole of Spring Boot, so we are able to adapt it to these functional bean definitions easily. If you step outside that limited scope, you can extend your Spring Cloud Function app by switching back to @Bean style configuration, or by using a hybrid approach. If you want to take advantage of Spring Boot autoconfiguration for integrations with external datastores, for example, you will need to use @EnableAutoConfiguration. Your functions can still be defined using the functional declarations if you want (i.e. the "hybrid" style), but in that case you will need to explicitly switch off the "full functional mode" using spring.functional.enabled=false so that Spring Boot can take back control.