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);
Table of Contents
@@ -134,18 +134,6 @@ public class DemoApplication {
-

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:

@@ -197,10 +185,14 @@ subclass).

-

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):

@@ -220,52 +212,162 @@ public class DemoApplication implements Function<String, String> {
-

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. -
-
- - -
-

Testing Functional Applications

-
-
-

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));
+}
+
+
+
+
+
+

Limitations of Functional Bean Declaration

+
+
+

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.

+
+
+
+

Testing Functional Applications

+
+
+
+

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:

@@ -281,25 +383,14 @@ public class FunctionalTests { @Test public void words() throws Exception { - Function<Flux<String>, Flux<String>> function = catalog.lookup(Function.class, - "function"); - assertThat(function.apply(Flux.just("foo")).blockFirst()).isEqualTo("FOO"); + Function<String, String> function = catalog.lookup(Function.class, + "uppercase"); + assertThat(function.apply("hello")).isEqualTo("HELLO"); } }
-
-

(The FunctionCatalog always returns functions from Flux to Flux, even if the user declares them with a simpler signature.)

-
-
- -
-

Limitations of Functional Bean Declaration

-
-
-

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.

-
diff --git a/reference/html/spring-cloud-function.html b/reference/html/spring-cloud-function.html index 21013bca0..9281523ba 100644 --- a/reference/html/spring-cloud-function.html +++ b/reference/html/spring-cloud-function.html @@ -115,10 +115,10 @@ $(addBlockSwitches);
  • Functional Bean Definitions
  • +
  • Testing Functional Applications
  • Dynamic Compilation
  • Serverless Platform Adapters
    -

    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):

    @@ -905,50 +900,161 @@ public class DemoApplication implements Function<String, String> {
    -

    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. -
    -
    - -
    -

    Testing Functional Applications

    -
    -

    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));
    +}
    +
    +
    +
    +
    +

    Limitations of Functional Bean Declaration

    +
    +

    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.

    +
    +
    + + +
    +

    Testing Functional Applications

    +
    +
    +

    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:

    @@ -964,24 +1070,14 @@ public class FunctionalTests { @Test public void words() throws Exception { - Function<Flux<String>, Flux<String>> function = catalog.lookup(Function.class, - "function"); - assertThat(function.apply(Flux.just("foo")).blockFirst()).isEqualTo("FOO"); + Function<String, String> function = catalog.lookup(Function.class, + "uppercase"); + assertThat(function.apply("hello")).isEqualTo("HELLO"); } }
    -
    -

    (The FunctionCatalog always returns functions from Flux to Flux, even if the user declares them with a simpler signature.)

    -
    -
    -
    -

    Limitations of Functional Bean Declaration

    -
    -

    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.

    -
    -