From a19742e19f82d605dfeaf244c241f176f36aca94 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 28 Feb 2019 09:05:40 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- .../multi__serverless_platform_adapters.html | 27 +++++++++++++- multi/multi_spring-cloud-function.html | 2 +- single/spring-cloud-function.html | 29 +++++++++++++-- spring-cloud-function.xml | 36 +++++++++++++++++++ 4 files changed, 90 insertions(+), 4 deletions(-) diff --git a/multi/multi__serverless_platform_adapters.html b/multi/multi__serverless_platform_adapters.html index 3ede28a26..ef1c757fe 100644 --- a/multi/multi__serverless_platform_adapters.html +++ b/multi/multi__serverless_platform_adapters.html @@ -14,7 +14,32 @@ has its own Spring Cloud Function adapter. And Java Function Invoker acts natively is an adapter for Spring Cloud Function jars.

10.1 AWS Lambda

The AWS adapter takes a Spring Cloud Function app and converts it to a form that can run in AWS Lambda.

10.1.1 Introduction

The adapter has a couple of generic request handlers that you can use. The most generic is SpringBootStreamHandler, which uses a Jackson ObjectMapper provided by Spring Boot to serialize and deserialize the objects in the function. There is also a SpringBootRequestHandler which you can extend, and provide the input and output types as type parameters (enabling AWS to inspect the class and do the JSON conversions itself).

If your app has more than one @Bean of type Function etc. then you can choose the one to use by configuring function.name (e.g. as FUNCTION_NAME environment variable in AWS). The functions are extracted from the Spring Cloud FunctionCatalog (searching first for Function then Consumer and finally Supplier).

10.1.2 Notes on JAR Layout

You don’t need the Spring Cloud Function Web or Stream adapter at runtime in Lambda, so you might need to exclude those before you create the JAR you send to AWS. A Lambda application has to be shaded, but a Spring Boot standalone application does not, so you can run the same app using 2 separate jars (as per the sample). The sample app creates 2 jar files, one with an aws classifier for deploying in Lambda, and one executable (thin) jar that includes spring-cloud-function-web at runtime. Spring Cloud Function will try and locate a "main class" for you from the JAR file manifest, using the Start-Class attribute (which will be added for you by the Spring Boot tooling if you use the starter parent). If there is no Start-Class in your manifest you can use an environment variable MAIN_CLASS when you deploy the function to AWS.

10.1.3 Upload

Build the sample under spring-cloud-function-samples/function-sample-aws and upload the -aws jar file to Lambda. The handler can be example.Handler or org.springframework.cloud.function.adapter.aws.SpringBootStreamHandler (FQN of the class, not a method reference, although Lambda does accept method references).

./mvnw -U clean package

Using the AWS command line tools it looks like this:

aws lambda create-function --function-name Uppercase --role arn:aws:iam::[USERID]:role/service-role/[ROLE] --zip-file fileb://function-sample-aws/target/function-sample-aws-2.0.0.BUILD-SNAPSHOT-aws.jar --handler org.springframework.cloud.function.adapter.aws.SpringBootStreamHandler --description "Spring Cloud Function Adapter Example" --runtime java8 --region us-east-1 --timeout 30 --memory-size 1024 --publish

The input type for the function in the AWS sample is a Foo with a single property called "value". So you would need this to test it:

{
   "value": "test"
-}
[Note]Note

The AWS sample app is written in the "functional" style (as an ApplicationContextInitializer). This is much faster on startup in Lambda than the traditional @Bean style, so if you don’t need @Beans (or @EnableAutoConfiguration) it’s a good choice. Warm starts are not affected.

10.1.4 Platfom Specific Features

HTTP and API Gateway

AWS has some platform-specific data types, including batching of messages, which is much more efficient than processing each one individually. To make use of these types you can write a function that depends on those types. Or you can rely on Spring to extract the data from the AWS types and convert it to a Spring Message. To do this you tell AWS that the function is of a specific generic handler type (depending on the AWS service) and provide a bean of type Function<Message<S>,Message<T>>, where S and T are your business data types. If there is more than one bean of type Function you may also need to configure the Spring Boot property function.name to be the name of the target bean (e.g. use FUNCTION_NAME as an environment variable).

The supported AWS services and generic handler types are listed below:

ServiceAWS TypesGeneric Handler 

API Gateway

APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent

org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler

 

Kinesis

KinesisEvent

org.springframework.cloud.function.adapter.aws.SpringBootKinesisEventHandler

 

For example, to deploy behind an API Gateway, use --handler org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler in your AWS command line (in via the UI) and define a @Bean of type Function<Message<Foo>,Message<Bar>> where Foo and Bar are POJO types (the data will be marshalled and unmarshalled by AWS using Jackson).

10.2 Azure Functions

The Azure adapter bootstraps a Spring Cloud Function context and channels function calls from the Azure framework into the user functions, using Spring Boot configuration where necessary. Azure Functions has quite a unique, but invasive programming model, involving annotations in user code that are specific to the platform. The easiest way to use it with Spring Cloud is to extend a base class and write a method in it with the @FunctionName annotation which delegates to a base class method.

This project provides an adapter layer for a Spring Cloud Function application onto Azure. +}

[Note]Note

The AWS sample app is written in the "functional" style (as an ApplicationContextInitializer). This is much faster on startup in Lambda than the traditional @Bean style, so if you don’t need @Beans (or @EnableAutoConfiguration) it’s a good choice. Warm starts are not affected.

10.1.4 Functional Bean Definitions

Your functions will start much quicker if you can use functional bean definitions instead of @Bean. To do this make your main class +an ApplicationContextInitalizer<GenericApplicationContext> and use the registerBean() methods in GenericApplicationContext to +create all the beans you need. You function need sto be registered as a bean of type FunctionRegistration so that the input and +output types can be accessed by the framework. There is an example in github (the AWS sample is written in this style). It would +look something like this:

@SpringBootApplication
+public class FuncApplication implements ApplicationContextInitializer<GenericApplicationContext> {
+
+	public static void main(String[] args) throws Exception {
+		FunctionalSpringApplication.run(FuncApplication.class, args);
+	}
+
+	public Function<Foo, Bar> function() {
+		return value -> new Bar(value.uppercase()));
+	}
+
+	@Override
+	public void initialize(GenericApplicationContext context) {
+		context.registerBean("function", FunctionRegistration.class,
+			() -> new FunctionRegistration<Function<Foo, Bar>>(function())
+				.type(FunctionType.from(Foo.class).to(Bar.class).getType()));
+	}
+
+}

10.1.5 Platfom Specific Features

HTTP and API Gateway

AWS has some platform-specific data types, including batching of messages, which is much more efficient than processing each one individually. To make use of these types you can write a function that depends on those types. Or you can rely on Spring to extract the data from the AWS types and convert it to a Spring Message. To do this you tell AWS that the function is of a specific generic handler type (depending on the AWS service) and provide a bean of type Function<Message<S>,Message<T>>, where S and T are your business data types. If there is more than one bean of type Function you may also need to configure the Spring Boot property function.name to be the name of the target bean (e.g. use FUNCTION_NAME as an environment variable).

The supported AWS services and generic handler types are listed below:

ServiceAWS TypesGeneric Handler 

API Gateway

APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent

org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler

 

Kinesis

KinesisEvent

org.springframework.cloud.function.adapter.aws.SpringBootKinesisEventHandler

 

For example, to deploy behind an API Gateway, use --handler org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler in your AWS command line (in via the UI) and define a @Bean of type Function<Message<Foo>,Message<Bar>> where Foo and Bar are POJO types (the data will be marshalled and unmarshalled by AWS using Jackson).

10.1.6 Custom Runtime

An AWS Lambda custom runtime can be created really easily using the HTTP export features in Spring Cloud Function Web. To make this work just add Spring Cloud Function AWS and Spring Cloud Function Web as dependencies in your project and set the following in your application.properties:

spring.cloud.function.web.export.enabled=true
+spring.cloud.function.web.export.source.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/next
+spring.cloud.function.web.export.sink.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/{{destination}}/response
+spring.cloud.function.web.export.sink.name=origin|uppercase

where "uppercase" is the name of your function ("origin" is the name of the Supplier that is provided by Spring Cloud Function Web). Then provide a bootstrap script in the root of your zip/jar that runs the Spring Boot application. The functional bean definition style works for custom runtimes too, and is faster than the @Bean style, so the example FuncApplication above would work. A custom runtime can start up much quicker even than a functional bean implementation of a Java lambda - it depends mostly on the number of classes you need to load at runtime. Spring doesn’t do very much here, so you can reduce the cold start time by only using primitive types in your function, for instance, and not doing any work in custom @PostConstruct initializers.

10.2 Azure Functions

The Azure adapter bootstraps a Spring Cloud Function context and channels function calls from the Azure framework into the user functions, using Spring Boot configuration where necessary. Azure Functions has quite a unique, but invasive programming model, involving annotations in user code that are specific to the platform. The easiest way to use it with Spring Cloud is to extend a base class and write a method in it with the @FunctionName annotation which delegates to a base class method.

This project provides an adapter layer for a Spring Cloud Function application onto Azure. You can write an app with a single @Bean of type Function and it will be deployable in Azure if you get the JAR file laid out right.

There is an AzureSpringBootRequestHandler which you must extend, and provide the input and output types as annotated method parameters (enabling Azure to inspect the class and create JSON bindings). The base class has two useful methods (handleRequest and handleOutput) to which you can delegate the actual function call, so mostly the function will only ever have one line.

Example:

public class FooHandler extends AzureSpringBootRequestHandler<Foo, Bar> {
 	@FunctionName("uppercase")
 	public Bar execute(
diff --git a/multi/multi_spring-cloud-function.html b/multi/multi_spring-cloud-function.html
index f1066d601..5241ee378 100644
--- a/multi/multi_spring-cloud-function.html
+++ b/multi/multi_spring-cloud-function.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Function
Spring Cloud Function
   Next
Spring Cloud Function
Table of Contents
1. Introduction
2. Getting Started
3. Building and Running a Function
4. Function Catalog and Flexible Function Signatures
4.1. Java 8 function support
4.2. Kotlin Lambda support
5. Standalone Web Applications
6. Standalone Streaming Applications
7. Deploying a Packaged Function
8. Functional Bean Definitions
8.1. Comparing Functional with Traditional Bean Definitions
8.2. Testing Functional Applications
8.3. Limitations of Functional Bean Declaration
9. Dynamic Compilation
10. Serverless Platform Adapters
10.1. AWS Lambda
10.1.1. Introduction
10.1.2. Notes on JAR Layout
10.1.3. Upload
10.1.4. Platfom Specific Features
HTTP and API Gateway
10.2. Azure Functions
10.2.1. Notes on JAR Layout
10.2.2. Build
10.2.3. Running the sample
10.3. Apache Openwhisk
10.3.1. Quick Start
   Next
   

\ No newline at end of file
+   Spring Cloud Function
Spring Cloud Function
   Next
Spring Cloud Function
Table of Contents
1. Introduction
2. Getting Started
3. Building and Running a Function
4. Function Catalog and Flexible Function Signatures
4.1. Java 8 function support
4.2. Kotlin Lambda support
5. Standalone Web Applications
6. Standalone Streaming Applications
7. Deploying a Packaged Function
8. Functional Bean Definitions
8.1. Comparing Functional with Traditional Bean Definitions
8.2. Testing Functional Applications
8.3. Limitations of Functional Bean Declaration
9. Dynamic Compilation
10. Serverless Platform Adapters
10.1. AWS Lambda
10.1.1. Introduction
10.1.2. Notes on JAR Layout
10.1.3. Upload
10.1.4. Functional Bean Definitions
10.1.5. Platfom Specific Features
HTTP and API Gateway
10.1.6. Custom Runtime
10.2. Azure Functions
10.2.1. Notes on JAR Layout
10.2.2. Build
10.2.3. Running the sample
10.3. Apache Openwhisk
10.3.1. Quick Start
   Next
   

\ No newline at end of file
diff --git a/single/spring-cloud-function.html b/single/spring-cloud-function.html
index c4afffb12..6ae0d492c 100644
--- a/single/spring-cloud-function.html
+++ b/single/spring-cloud-function.html
@@ -1,6 +1,6 @@
 
       
-   Spring Cloud Function
Spring Cloud Function
Table of Contents
1. Introduction
2. Getting Started
3. Building and Running a Function
4. Function Catalog and Flexible Function Signatures
4.1. Java 8 function support
4.2. Kotlin Lambda support
5. Standalone Web Applications
6. Standalone Streaming Applications
7. Deploying a Packaged Function
8. Functional Bean Definitions
8.1. Comparing Functional with Traditional Bean Definitions
8.2. Testing Functional Applications
8.3. Limitations of Functional Bean Declaration
9. Dynamic Compilation
10. Serverless Platform Adapters
10.1. AWS Lambda
10.1.1. Introduction
10.1.2. Notes on JAR Layout
10.1.3. Upload
10.1.4. Platfom Specific Features
HTTP and API Gateway
10.2. Azure Functions
10.2.1. Notes on JAR Layout
10.2.2. Build
10.2.3. Running the sample
10.3. Apache Openwhisk
10.3.1. Quick Start
Mark Fisher, Dave Syer, Oleg Zhurakousky
1. Introduction
Spring Cloud Function is a project with the following high-level goals:
  • Promote the implementation of business logic via functions.
  • Decouple the development lifecycle of business logic from any specific runtime target so that the same code can run as a web endpoint, a stream processor, or a task.
  • Support a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).
  • Enable Spring Boot features (auto-configuration, dependency injection, metrics) on serverless providers.
It abstracts away all of the transport details and
+   Spring Cloud Function
Spring Cloud Function
Table of Contents
1. Introduction
2. Getting Started
3. Building and Running a Function
4. Function Catalog and Flexible Function Signatures
4.1. Java 8 function support
4.2. Kotlin Lambda support
5. Standalone Web Applications
6. Standalone Streaming Applications
7. Deploying a Packaged Function
8. Functional Bean Definitions
8.1. Comparing Functional with Traditional Bean Definitions
8.2. Testing Functional Applications
8.3. Limitations of Functional Bean Declaration
9. Dynamic Compilation
10. Serverless Platform Adapters
10.1. AWS Lambda
10.1.1. Introduction
10.1.2. Notes on JAR Layout
10.1.3. Upload
10.1.4. Functional Bean Definitions
10.1.5. Platfom Specific Features
HTTP and API Gateway
10.1.6. Custom Runtime
10.2. Azure Functions
10.2.1. Notes on JAR Layout
10.2.2. Build
10.2.3. Running the sample
10.3. Apache Openwhisk
10.3.1. Quick Start
Mark Fisher, Dave Syer, Oleg Zhurakousky
1. Introduction
Spring Cloud Function is a project with the following high-level goals:
  • Promote the implementation of business logic via functions.
  • Decouple the development lifecycle of business logic from any specific runtime target so that the same code can run as a web endpoint, a stream processor, or a task.
  • Support a uniform programming model across serverless providers, as well as the ability to run standalone (locally or in a PaaS).
  • Enable Spring Boot features (auto-configuration, dependency injection, metrics) on serverless providers.
It abstracts away all of the transport details and
 infrastructure, allowing the developer to keep all the familiar tools
 and processes, and focus firmly on business logic.
Here’s a complete, executable, testable Spring Boot application
 (implementing a simple string manipulation):
@SpringBootApplication
@@ -207,7 +207,32 @@ has its own Spring Cloud Function adapter. And
 Java Function
 Invoker acts natively is an adapter for Spring Cloud Function jars.
10.1 AWS Lambda
The AWS adapter takes a Spring Cloud Function app and converts it to a form that can run in AWS Lambda.
10.1.1 Introduction
The adapter has a couple of generic request handlers that you can use. The most generic is SpringBootStreamHandler, which uses a Jackson ObjectMapper provided by Spring Boot to serialize and deserialize the objects in the function. There is also a SpringBootRequestHandler which you can extend, and provide the input and output types as type parameters (enabling AWS to inspect the class and do the JSON conversions itself).
If your app has more than one @Bean of type Function etc. then you can choose the one to use by configuring function.name (e.g. as FUNCTION_NAME environment variable in AWS). The functions are extracted from the Spring Cloud FunctionCatalog (searching first for Function then Consumer and finally Supplier).
10.1.2 Notes on JAR Layout
You don’t need the Spring Cloud Function Web or Stream adapter at runtime in Lambda, so you might need to exclude those before you create the JAR you send to AWS. A Lambda application has to be shaded, but a Spring Boot standalone application does not, so you can run the same app using 2 separate jars (as per the sample). The sample app creates 2 jar files, one with an aws classifier for deploying in Lambda, and one executable (thin) jar that includes spring-cloud-function-web at runtime. Spring Cloud Function will try and locate a "main class" for you from the JAR file manifest, using the Start-Class attribute (which will be added for you by the Spring Boot tooling if you use the starter parent). If there is no Start-Class in your manifest you can use an environment variable MAIN_CLASS when you deploy the function to AWS.
10.1.3 Upload
Build the sample under spring-cloud-function-samples/function-sample-aws and upload the -aws jar file to Lambda. The handler can be example.Handler or org.springframework.cloud.function.adapter.aws.SpringBootStreamHandler (FQN of the class, not a method reference, although Lambda does accept method references).
./mvnw -U clean package
Using the AWS command line tools it looks like this:
aws lambda create-function --function-name Uppercase --role arn:aws:iam::[USERID]:role/service-role/[ROLE] --zip-file fileb://function-sample-aws/target/function-sample-aws-2.0.0.BUILD-SNAPSHOT-aws.jar --handler org.springframework.cloud.function.adapter.aws.SpringBootStreamHandler --description "Spring Cloud Function Adapter Example" --runtime java8 --region us-east-1 --timeout 30 --memory-size 1024 --publish
The input type for the function in the AWS sample is a Foo with a single property called "value". So you would need this to test it:
{
   "value": "test"
-}
[Note]Note
The AWS sample app is written in the "functional" style (as an ApplicationContextInitializer). This is much faster on startup in Lambda than the traditional @Bean style, so if you don’t need @Beans (or @EnableAutoConfiguration) it’s a good choice. Warm starts are not affected.
10.1.4 Platfom Specific Features
HTTP and API Gateway
AWS has some platform-specific data types, including batching of messages, which is much more efficient than processing each one individually. To make use of these types you can write a function that depends on those types. Or you can rely on Spring to extract the data from the AWS types and convert it to a Spring Message. To do this you tell AWS that the function is of a specific generic handler type (depending on the AWS service) and provide a bean of type Function<Message<S>,Message<T>>, where S and T are your business data types. If there is more than one bean of type Function you may also need to configure the Spring Boot property function.name to be the name of the target bean (e.g. use FUNCTION_NAME as an environment variable).
The supported AWS services and generic handler types are listed below:
ServiceAWS TypesGeneric Handler 
API Gateway
APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent
org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler
 
Kinesis
KinesisEvent
org.springframework.cloud.function.adapter.aws.SpringBootKinesisEventHandler
 
For example, to deploy behind an API Gateway, use --handler org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler in your AWS command line (in via the UI) and define a @Bean of type Function<Message<Foo>,Message<Bar>> where Foo and Bar are POJO types (the data will be marshalled and unmarshalled by AWS using Jackson).
10.2 Azure Functions
The Azure adapter bootstraps a Spring Cloud Function context and channels function calls from the Azure framework into the user functions, using Spring Boot configuration where necessary. Azure Functions has quite a unique, but invasive programming model, involving annotations in user code that are specific to the platform. The easiest way to use it with Spring Cloud is to extend a base class and write a method in it with the @FunctionName annotation which delegates to a base class method.
This project provides an adapter layer for a Spring Cloud Function application onto Azure.
+}
[Note]Note
The AWS sample app is written in the "functional" style (as an ApplicationContextInitializer). This is much faster on startup in Lambda than the traditional @Bean style, so if you don’t need @Beans (or @EnableAutoConfiguration) it’s a good choice. Warm starts are not affected.
10.1.4 Functional Bean Definitions
Your functions will start much quicker if you can use functional bean definitions instead of @Bean. To do this make your main class
+an ApplicationContextInitalizer<GenericApplicationContext> and use the registerBean() methods in GenericApplicationContext to
+create all the beans you need. You function need sto be registered as a bean of type FunctionRegistration so that the input and
+output types can be accessed by the framework. There is an example in github (the AWS sample is written in this style). It would
+look something like this:
@SpringBootApplication
+public class FuncApplication implements ApplicationContextInitializer<GenericApplicationContext> {
+
+	public static void main(String[] args) throws Exception {
+		FunctionalSpringApplication.run(FuncApplication.class, args);
+	}
+
+	public Function<Foo, Bar> function() {
+		return value -> new Bar(value.uppercase()));
+	}
+
+	@Override
+	public void initialize(GenericApplicationContext context) {
+		context.registerBean("function", FunctionRegistration.class,
+			() -> new FunctionRegistration<Function<Foo, Bar>>(function())
+				.type(FunctionType.from(Foo.class).to(Bar.class).getType()));
+	}
+
+}
10.1.5 Platfom Specific Features
HTTP and API Gateway
AWS has some platform-specific data types, including batching of messages, which is much more efficient than processing each one individually. To make use of these types you can write a function that depends on those types. Or you can rely on Spring to extract the data from the AWS types and convert it to a Spring Message. To do this you tell AWS that the function is of a specific generic handler type (depending on the AWS service) and provide a bean of type Function<Message<S>,Message<T>>, where S and T are your business data types. If there is more than one bean of type Function you may also need to configure the Spring Boot property function.name to be the name of the target bean (e.g. use FUNCTION_NAME as an environment variable).
The supported AWS services and generic handler types are listed below:
ServiceAWS TypesGeneric Handler 
API Gateway
APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent
org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler
 
Kinesis
KinesisEvent
org.springframework.cloud.function.adapter.aws.SpringBootKinesisEventHandler
 
For example, to deploy behind an API Gateway, use --handler org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler in your AWS command line (in via the UI) and define a @Bean of type Function<Message<Foo>,Message<Bar>> where Foo and Bar are POJO types (the data will be marshalled and unmarshalled by AWS using Jackson).
10.1.6 Custom Runtime
An AWS Lambda custom runtime can be created really easily using the HTTP export features in Spring Cloud Function Web. To make this work just add Spring Cloud Function AWS and Spring Cloud Function Web as dependencies in your project and set the following in your application.properties:
spring.cloud.function.web.export.enabled=true
+spring.cloud.function.web.export.source.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/next
+spring.cloud.function.web.export.sink.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/{{destination}}/response
+spring.cloud.function.web.export.sink.name=origin|uppercase
where "uppercase" is the name of your function ("origin" is the name of the Supplier that is provided by Spring Cloud Function Web). Then provide a bootstrap script in the root of your zip/jar that runs the Spring Boot application. The functional bean definition style works for custom runtimes too, and is faster than the @Bean style, so the example FuncApplication above would work. A custom runtime can start up much quicker even than a functional bean implementation of a Java lambda - it depends mostly on the number of classes you need to load at runtime. Spring doesn’t do very much here, so you can reduce the cold start time by only using primitive types in your function, for instance, and not doing any work in custom @PostConstruct initializers.
10.2 Azure Functions
The Azure adapter bootstraps a Spring Cloud Function context and channels function calls from the Azure framework into the user functions, using Spring Boot configuration where necessary. Azure Functions has quite a unique, but invasive programming model, involving annotations in user code that are specific to the platform. The easiest way to use it with Spring Cloud is to extend a base class and write a method in it with the @FunctionName annotation which delegates to a base class method.
This project provides an adapter layer for a Spring Cloud Function application onto Azure.
 You can write an app with a single @Bean of type Function and it will be deployable in Azure if you get the JAR file laid out right.
There is an AzureSpringBootRequestHandler which you must extend, and provide the input and output types as annotated method parameters (enabling Azure to inspect the class and create JSON bindings). The base class has two useful methods (handleRequest and handleOutput) to which you can delegate the actual function call, so mostly the function will only ever have one line.
Example:
public class FooHandler extends AzureSpringBootRequestHandler<Foo, Bar> {
 	@FunctionName("uppercase")
 	public Bar execute(
diff --git a/spring-cloud-function.xml b/spring-cloud-function.xml
index d35014d24..bc7d841eb 100644
--- a/spring-cloud-function.xml
+++ b/spring-cloud-function.xml
@@ -540,6 +540,33 @@ Invoker acts natively is an adapter for Spring Cloud Function jars.The AWS sample app is written in the "functional" style (as an ApplicationContextInitializer). This is much faster on startup in Lambda than the traditional @Bean style, so if you don’t need @Beans (or @EnableAutoConfiguration) it’s a good choice. Warm starts are not affected.
 
 
+

+Functional Bean Definitions
+Your functions will start much quicker if you can use functional bean definitions instead of @Bean. To do this make your main class
+an ApplicationContextInitalizer<GenericApplicationContext> and use the registerBean() methods in GenericApplicationContext to
+create all the beans you need. You function need sto be registered as a bean of type FunctionRegistration so that the input and
+output types can be accessed by the framework. There is an example in github (the AWS sample is written in this style). It would
+look something like this:
+@SpringBootApplication
+public class FuncApplication implements ApplicationContextInitializer<GenericApplicationContext> {
+
+	public static void main(String[] args) throws Exception {
+		FunctionalSpringApplication.run(FuncApplication.class, args);
+	}
+
+	public Function<Foo, Bar> function() {
+		return value -> new Bar(value.uppercase()));
+	}
+
+	@Override
+	public void initialize(GenericApplicationContext context) {
+		context.registerBean("function", FunctionRegistration.class,
+			() -> new FunctionRegistration<Function<Foo, Bar>>(function())
+				.type(FunctionType.from(Foo.class).to(Bar.class).getType()));
+	}
+
+}
+

 

 Platfom Specific Features
 

@@ -579,6 +606,15 @@ Invoker acts natively is an adapter for Spring Cloud Function jars.For example, to deploy behind an API Gateway, use --handler org.springframework.cloud.function.adapter.aws.SpringBootApiGatewayRequestHandler in your AWS command line (in via the UI) and define a @Bean of type Function<Message<Foo>,Message<Bar>> where Foo and Bar are POJO types (the data will be marshalled and unmarshalled by AWS using Jackson).
 

 

+

+Custom Runtime
+An AWS Lambda custom runtime can be created really easily using the HTTP export features in Spring Cloud Function Web. To make this work just add Spring Cloud Function AWS and Spring Cloud Function Web as dependencies in your project and set the following in your application.properties:
+spring.cloud.function.web.export.enabled=true
+spring.cloud.function.web.export.source.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/next
+spring.cloud.function.web.export.sink.url=http://${AWS_LAMBDA_RUNTIME_API:localhost}/2018-06-01/runtime/invocation/{{destination}}/response
+spring.cloud.function.web.export.sink.name=origin|uppercase
+where "uppercase" is the name of your function ("origin" is the name of the Supplier that is provided by Spring Cloud Function Web). Then provide a bootstrap script in the root of your zip/jar that runs the Spring Boot application. The functional bean definition style works for custom runtimes too, and is faster than the @Bean style, so the example FuncApplication above would work. A custom runtime can start up much quicker even than a functional bean implementation of a Java lambda - it depends mostly on the number of classes you need to load at runtime. Spring doesn’t do very much here, so you can reduce the cold start time by only using primitive types in your function, for instance, and not doing any work in custom @PostConstruct initializers.
+

 
 

 Azure Functions