Stateful Functions offers a platform for building robust, stateful event-driven applications.
It provides fine-grained control over state and time, which allows for the implementation of advanced systems.
In this step-by-step guide you’ll learn how to build a stateful applications with the Stateful Functions API.
Like all great introductions in software, this walkthrough will start at the beginning: saying hello.
The application will run a simple function that accepts a request and responds with a greeting.
It will not attempt to cover all the complexities of application development, but instead focus on building a stateful function — which is where you will implement your business logic.
This walkthrough assumes that you have some familiarity with Python, but you should be able to follow along even if you are coming from a different programming language.
If you want to follow along, you will require a computer with Python 3 along with Docker.
Note: Each code block within this walkthrough may not contain the full surrounding class for brevity.
The full code is available on at the bottom of this page.
You can download a zip file with a skeleton project by clicking here.
Note: The Stateful Functions project does not publish snapshot versions of the Python SDK to PyPI.
Please consider using a stable version of this guide.
After unzipping the package, you will find a number of files.
These include dockerfiles and data generators to run this walkthrough in a local self contained environment.
Start With Events
Stateful Functions is an event driven system, so development begins by defining our events.
The greeter application will define its events using protocol buffers.
When a greet request for a particular user is ingested, it will be routed to the appropriate function.
The response will be returned with an appropriate greeting.
The third type, SeenCount, is a utility class that will be used latter on to help manage the number of times a user has been seen so far.
Our First Function
Under the hood, messages are processed using stateful functions, which is any two argument function that is bound to the StatefulFunction runtime.
Functions are bound to the runtime with the @function.bind decorator.
When binding a function, it is annotated with a function type.
This is the name used to reference this function when sending it messages.
When you open the file greeter/greeter.py you should see the following code.
A stateful function takes two arguments, a context and message.
The context provides access to stateful functions runtime features such as state management and message passing.
You will explore some of these features as you progress through this walkthrough.
The other parameter is the input message that has been passed to this function.
By default messages are passed around as protobuf Any.
If a function only accepts a known type, you can override the message type using Python 3 type syntax.
This way you do not need to unwrap the message or check types.
Sending A Response
Stateful Functions accept messages and can also send them out.
Messages can be sent to other functions, as well as external systems (or egress).
One popular external system is Apache Kafka.
As a first step, lets update our function in greeter/greeter.py to respond to each input by sending a greeting to a Kafka topic.
For each message, a response is constructed and sent to a kafka topic call greetings partitioned by name.
The egress_message is sent to a an egress named example/greets.
This identifier points to a particular Kafka cluster and is configured on deployment below.
A Stateful Hello
This is a great start, but does not show off the real power of stateful functions - working with state.
Suppose you want to generate a personalized response for each user depending on how many times they have sent a request.
To “remember” information across multiple greeting messages, you then need to associate a persisted value field (seen_count) to the Greet function.
For each user, functions can now track how many times they have been seen.
The state, seen_count is always scoped to the current name so it can track each user independently.
Wiring It All Together
Stateful Function applications communicate with the Apache Flink runtime using http.
The Python SDK ships with a RequestReplyHandler that automatically dispatches function calls based on RESTful HTTP POSTS.
The RequestReplyHandler may be exposed using any HTTP framework.
One popular Python web framework is Flask.
It can be used to quickly and easily expose an application to the Apache Flink runtime.
Configuring for Runtime
The Stateful Function runtime makes requests to the greeter function by making http calls to the Flask server.
To do that, it needs to know what endpoint it can use to reach the server.
This is also a good time to configure our connection to the input and output Kafka topics.
The configuration is in a file called module.yaml.
This configuration does a few interesting things.
The first is to declare our function, example/greeter.
It includes the endpoint by which it is reachable along with the states the function has access to.
The ingress is the input Kafka topic that routes GreetRequest messages to the function.
Along with basic properties like broker address and consumer group, it contains a list of targets.
These are the functions each message will be sent to.
The egress is the output Kafka cluster.
It contains broker specific configurations but allows each message to route to any topic.
Now that the greeter application has been built it is time to deploy.
The simplest way to deploy a Stateful Function application is by using the community provided base image and loading your module.
The base image provides the Stateful Function runtime, it will use the provided module.yaml to configure for this specific job.
This can be found in the Dockerfile in the root directory.
You can now run this application locally using the provided Docker setup.
Then, to see the example in actions, see what comes out of the topic greetings:
Want To Go Further?
This Greeter never forgets a user.
Try and modify the function so that it will reset the seen_count for any user that spends more than 60 seconds without interacting with the system.