326 lines
10 KiB
Plaintext
326 lines
10 KiB
Plaintext
= Functional Bean Definitions
|
|
|
|
Spring Cloud Function supports a "functional" style of bean declarations for small apps where you need fast startup. The functional style of bean declaration was a feature of Spring Framework 5.0 with significant enhancements in 5.1.
|
|
|
|
== Comparing Functional with Traditional Bean Definitions
|
|
|
|
Here's a vanilla Spring Cloud Function application from with the
|
|
familiar `@Configuration` and `@Bean` declaration style:
|
|
|
|
[source,json]
|
|
----
|
|
|
|
@SpringBootApplication
|
|
public class DemoApplication {
|
|
|
|
@Bean
|
|
public Function<String, String> uppercase() {
|
|
return value -> value.toUpperCase();
|
|
}
|
|
|
|
public static void main(String[] args) {
|
|
SpringApplication.run(DemoApplication.class, args);
|
|
}
|
|
|
|
}
|
|
----
|
|
|
|
Now for the functional beans: the user application code can be recast into "functional"
|
|
form, like this:
|
|
|
|
[source,json]
|
|
----
|
|
@SpringBootConfiguration
|
|
public class DemoApplication implements ApplicationContextInitializer<GenericApplicationContext> {
|
|
|
|
public static void main(String[] args) {
|
|
FunctionalSpringApplication.run(DemoApplication.class, args);
|
|
}
|
|
|
|
public Function<String, String> uppercase() {
|
|
return value -> value.toUpperCase();
|
|
}
|
|
|
|
@Override
|
|
public void initialize(GenericApplicationContext context) {
|
|
context.registerBean("demo", FunctionRegistration.class,
|
|
() -> new FunctionRegistration<>(uppercase())
|
|
.type(FunctionTypeUtils.functionType(String.class, String.class)));
|
|
}
|
|
|
|
}
|
|
----
|
|
|
|
The main differences are:
|
|
|
|
* The main class is an `ApplicationContextInitializer`.
|
|
|
|
* The `@Bean` methods have been converted to calls to `context.registerBean()`
|
|
|
|
* The `@SpringBootApplication` has been replaced with
|
|
`@SpringBootConfiguration` to signify that we are not enabling Spring
|
|
Boot autoconfiguration, and yet still marking the class as an "entry
|
|
point".
|
|
|
|
* The `SpringApplication` from Spring Boot has been replaced with a
|
|
`FunctionalSpringApplication` from Spring Cloud Function (it's a
|
|
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`.
|
|
|
|
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):
|
|
|
|
[source,json]
|
|
----
|
|
@SpringBootConfiguration
|
|
public class DemoApplication implements Function<String, String> {
|
|
|
|
public static void main(String[] args) {
|
|
FunctionalSpringApplication.run(DemoApplication.class, args);
|
|
}
|
|
|
|
@Override
|
|
public String apply(String value) {
|
|
return value.toUpperCase();
|
|
}
|
|
|
|
}
|
|
----
|
|
|
|
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.
|
|
|
|
Suppose you have
|
|
[source, java]
|
|
----
|
|
@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()));
|
|
}
|
|
|
|
}
|
|
----
|
|
|
|
You register it as such:
|
|
|
|
[source, java]
|
|
----
|
|
@Override
|
|
public void initialize(GenericApplicationContext context) {
|
|
context.registerBean("function", FunctionRegistration.class,
|
|
() -> new FunctionRegistration<>(new CustomFunction()).type(CustomFunction.class));
|
|
}
|
|
----
|
|
|
|
[[limitations-of-functional-bean-declaration]]
|
|
== 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.
|
|
|
|
[[function_visualization]]
|
|
== Function visualization and control
|
|
|
|
Spring Cloud Function supports visualization of functions available in `FunctionCatalog` through Actuator endpoints as well as programmatic way.
|
|
|
|
[[programmatic-way]]
|
|
=== Programmatic way
|
|
|
|
To see function available within your application context programmatically all you need is access to `FunctionCatalog`. There you can
|
|
finds methods to get the size of the catalog, lookup functions as well as list the names of all the available functions.
|
|
|
|
For example,
|
|
|
|
[source,java]
|
|
----
|
|
FunctionCatalog functionCatalog = context.getBean(FunctionCatalog.class);
|
|
int size = functionCatalog.size(); // will tell you how many functions available in catalog
|
|
Set<String> names = functionCatalog.getNames(null); will list the names of all the Function, Suppliers and Consumers available in catalog
|
|
. . .
|
|
----
|
|
|
|
[[actuator]]
|
|
=== Actuator
|
|
Since actuator and web are optional, you must first add one of the web dependencies as well as add the actuator dependency manually.
|
|
The following example shows how to add the dependency for the Web framework:
|
|
|
|
[source,xml]
|
|
----
|
|
<dependency>
|
|
<groupId>org.springframework.boot</groupId>
|
|
<artifactId>spring-boot-starter-web</artifactId>
|
|
</dependency>
|
|
----
|
|
|
|
The following example shows how to add the dependency for the WebFlux framework:
|
|
|
|
[source,xml]
|
|
----
|
|
<dependency>
|
|
<groupId>org.springframework.boot</groupId>
|
|
<artifactId>spring-boot-starter-webflux</artifactId>
|
|
</dependency>
|
|
----
|
|
|
|
You can add the Actuator dependency as follows:
|
|
[source,xml]
|
|
----
|
|
<dependency>
|
|
<groupId>org.springframework.boot</groupId>
|
|
<artifactId>spring-boot-starter-actuator</artifactId>
|
|
</dependency>
|
|
----
|
|
|
|
You must also enable the `functions` actuator endpoints by setting the following property: `--management.endpoints.web.exposure.include=functions`.
|
|
|
|
Access the following URL to see the functions in FunctionCatalog:
|
|
`http://<host>:<port>/actuator/functions`
|
|
|
|
For example,
|
|
[source,text]
|
|
----
|
|
curl http://localhost:8080/actuator/functions
|
|
----
|
|
|
|
Your output should look something like this:
|
|
[source,text]
|
|
----
|
|
{"charCounter":
|
|
{"type":"FUNCTION","input-type":"string","output-type":"integer"},
|
|
"logger":
|
|
{"type":"CONSUMER","input-type":"string"},
|
|
"functionRouter":
|
|
{"type":"FUNCTION","input-type":"object","output-type":"object"},
|
|
"words":
|
|
{"type":"SUPPLIER","output-type":"string"}. . .
|
|
----
|
|
|
|
[[testing-functional-applications]]
|
|
== 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:
|
|
|
|
[source, java]
|
|
----
|
|
@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:
|
|
|
|
[source, java]
|
|
----
|
|
@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:
|
|
|
|
[source, java]
|
|
----
|
|
@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
|
|
|
|
[source, xml, subs=attributes+]
|
|
----
|
|
<parent>
|
|
<groupId>org.springframework.boot</groupId>
|
|
<artifactId>spring-boot-starter-parent</artifactId>
|
|
<relativePath/> <!-- lookup parent from repository -->
|
|
</parent>
|
|
. . . .
|
|
<dependency>
|
|
<groupId>org.springframework.cloud</groupId>
|
|
<artifactId>spring-cloud-function-web</artifactId>
|
|
<version>{project-version}</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>
|
|
</dependency>
|
|
----
|
|
|
|
Or you could write a test for a non-HTTP app using just the `FunctionCatalog`. For example:
|
|
|
|
[source, java]
|
|
----
|
|
@FunctionalSpringBootTest
|
|
public class FunctionalTests {
|
|
|
|
@Autowired
|
|
private FunctionCatalog catalog;
|
|
|
|
@Test
|
|
public void words() {
|
|
Function<String, String> function = catalog.lookup(Function.class,
|
|
"uppercase");
|
|
assertThat(function.apply("hello")).isEqualTo("HELLO");
|
|
}
|
|
|
|
}
|
|
----
|