|
| 1 | +--- |
| 2 | +title: "Announcing OpenFunction 1.1.0: Support Dapr State Management and Refactor Function Triggers" |
| 3 | +linkTitle: "Release v1.1.0" |
| 4 | +date: 2023-06-12 |
| 5 | +weight: 92 |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +OpenFunction is a cloud-native open-source FaaS (Function as a Service) platform aiming to let you focus on your business logic only. Today, we are thrilled to announce the general availability of OpenFunction 1.1.0. |
| 10 | + |
| 11 | +In this release, we have added the v1beta2 API and support Dapr State management. In addition, we enhanced some features and fixed bugs, making OpenFunction more stable and easy to use. |
| 12 | + |
| 13 | +The following introduces the major updates. |
| 14 | + |
| 15 | +## Add the v1beta2 API |
| 16 | + |
| 17 | +In this release, we have added the v1beta2 API. The v1beta1 API has been deprecated and will be removed. You can learn more about the v1beta2 API from this [proposal](https://github.com/OpenFunction/OpenFunction/blob/main/docs/proposals/20230330-support-dapr-state-management.md). |
| 18 | + |
| 19 | +### Support Dapr state management |
| 20 | + |
| 21 | +Previously, OpenFunction supports the pub/sub and bindings building blocks, and state management is a building block that is useful for stateful functions. With the use of state store components, you can build functions with persistent state, allowing them to save and restore their own states. |
| 22 | + |
| 23 | +You can define state stores in Function CR, and OpenFunction will manage the corresponding Dapr components. |
| 24 | + |
| 25 | +The functions can use the encapsulated state management API of Dapr to save, read, and query key/value pairs in the defined state storage. |
| 26 | + |
| 27 | +## Refactor function triggers |
| 28 | + |
| 29 | +Previously, we use `runtime: knative` and `runtime: async` to distinguish sync and async functions, which is sort of difficult. Actually the difference between sync and async functions lies in the trigger type: |
| 30 | + |
| 31 | +- Sync functions are triggered by `HTTP` events, which are defined by specifying `runtime: knative`. |
| 32 | + |
| 33 | +- Async functions are triggered by events from components of `Dapr bindings` or `Dapr pubsub`. `runtime: async` and `inputs` have to be used together to specify triggers for async functions. |
| 34 | + |
| 35 | +Now we use `triggers` to replace `runtime` and `inputs`. |
| 36 | + |
| 37 | +`HTTP Trigger` triggers a function with an HTTP request. You can define an `HTTP Trigger` for a function like this: |
| 38 | + |
| 39 | +```yaml |
| 40 | +apiVersion: core.openfunction.io/v1beta2 |
| 41 | +kind: Function |
| 42 | +metadata: |
| 43 | + name: function-sample |
| 44 | +spec: |
| 45 | + serving: |
| 46 | + triggers: |
| 47 | + http: |
| 48 | + port: 8080 |
| 49 | + route: |
| 50 | + rules: |
| 51 | + - matches: |
| 52 | + - path: |
| 53 | + type: PathPrefix |
| 54 | + value: /echo |
| 55 | +``` |
| 56 | +
|
| 57 | +`Dapr Trigger` triggers a function with events from `Dapr bindings` or `Dapr pubsub`. You can define a function with `Dapr Trigger` like this: |
| 58 | + |
| 59 | +```yaml |
| 60 | +apiVersion: core.openfunction.io/v1beta2 |
| 61 | +kind: Function |
| 62 | +metadata: |
| 63 | + name: logs-async-handler |
| 64 | + namespace: default |
| 65 | +spec: |
| 66 | + serving: |
| 67 | + bindings: |
| 68 | + kafka-receiver: |
| 69 | + metadata: |
| 70 | + - name: brokers |
| 71 | + value: kafka-server-kafka-brokers:9092 |
| 72 | + - name: authRequired |
| 73 | + value: "false" |
| 74 | + - name: publishTopic |
| 75 | + value: logs |
| 76 | + - name: topics |
| 77 | + value: logs |
| 78 | + - name: consumerGroup |
| 79 | + value: logs-handler |
| 80 | + type: bindings.kafka |
| 81 | + version: v1 |
| 82 | + triggers: |
| 83 | + dapr: |
| 84 | + - name: kafka-receiver |
| 85 | + type: bindings.kafka |
| 86 | +``` |
| 87 | + |
| 88 | +## Other enhancements |
| 89 | + |
| 90 | +- Delete the `lastTransitionTime` field from the gateway status to prevent frequent triggering of reconcile. |
| 91 | +- Allow to set scopes when creating Dapr components. |
| 92 | +- Support the ability to set cache images to improve build performance when using OpenFunction strategies. |
| 93 | +- Support the ability to set bash images of OpenFunction strategies. |
| 94 | + |
| 95 | +These are the main feature changes in OpenFunction v1.1.0 and we would like to thank all contributors for your contributions. If you are looking for an efficient and flexible cloud-native function development platform, OpenFunction v1.1.0 is the perfect choice for you. |
| 96 | + |
| 97 | +For more details and documentation, please visit our website and GitHub repo. |
| 98 | + |
| 99 | +- [Official Website](https://openfunction.dev/): https://openfunction.dev/ |
| 100 | +- [Github](https://github.com/OpenFunction/OpenFunction/releases/tag/v1.1.0):https://github.com/OpenFunction/OpenFunction/releases/tag/v1.1.0 |
0 commit comments