This is an automated email from the ASF dual-hosted git repository.
tzulitai pushed a commit to branch release-3.0
in repository https://gitbox.apache.org/repos/asf/flink-statefun.git
commit 71e8de7f7046cb7b65b533f1f336bdeeebeb475b
Author: ariskk <a...@ariskk.com>
AuthorDate: Sat Apr 24 11:31:08 2021 +0100
[hotfix][docs] Fix typos in concepts
This closes #229.
---
docs/content/docs/concepts/application-building-blocks.md | 6 +++---
docs/content/docs/concepts/distributed_architecture.md | 4 ++--
docs/content/docs/concepts/logical.md | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/docs/content/docs/concepts/application-building-blocks.md
b/docs/content/docs/concepts/application-building-blocks.md
index d82ca23..996a314 100644
--- a/docs/content/docs/concepts/application-building-blocks.md
+++ b/docs/content/docs/concepts/application-building-blocks.md
@@ -26,7 +26,7 @@ under the License.
# Application Building Blocks
-Stateful Functions provides a framework for building event drivent
applications. Here, we explain important aspects of Stateful Function’s
architecture.
+Stateful Functions provides a framework for building event driven
applications. Here, we explain important aspects of Stateful Function’s
architecture.
## Event Ingress
@@ -36,7 +36,7 @@ Stateful Function applications sit squarely in the event
driven space, so the na
In Stateful Functions, the component that ingests records into the system is
called an event ingress.
-This can be anything from a Kafka topic, to a messsage queue, to an http
request - anything that can get data into the system and trigger the intitial
functions to begin computation.
+This can be anything from a Kafka topic, to a message queue, to an http
request - anything that can get data into the system and trigger the initial
functions to begin computation.
## Stateful Functions
@@ -63,7 +63,7 @@ When inside a function, while it is performing some
computation, you are always
### Fault Tolerance
-For both state and messaging, Stateful Functions is able to provide the
exactly-once guarantees users expect from a modern data processessing framework.
+For both state and messaging, Stateful Functions is able to provide the
exactly-once guarantees users expect from a modern data processing framework.
{{< img width="80%" src="/fig/concepts/statefun-app-fault-tolerance.svg" >}}
diff --git a/docs/content/docs/concepts/distributed_architecture.md
b/docs/content/docs/concepts/distributed_architecture.md
index 3c64181..bebdf99 100644
--- a/docs/content/docs/concepts/distributed_architecture.md
+++ b/docs/content/docs/concepts/distributed_architecture.md
@@ -47,7 +47,7 @@ In addition to the Apache Flink processes, a full deployment
requires [ZooKeeper
## Logical Co-location, Physical Separation
-A core principle of many Stream Processors is that application logic and the
application state must be co-located. That approach is the basis for their
out-of-the box consistency. Stateful Functions takes a unique approach to that
by *logically co-locating* state and compute, but allowing to *physically
separate* them.
+A core principle of many Stream Processors is that application logic, and the
application state must be co-located. That approach is the basis for their
out-of-the box consistency. Stateful Functions takes a unique approach to that
by *logically co-locating* state and compute, but allowing to *physically
separate* them.
- *Logical co-location:* Messaging, state access/updates and function
invocations are managed tightly together, in the same way as in Flink's
DataStream API. State is sharded by key, and messages are routed to the state
by key. There is a single writer per key at a time, also scheduling the
function invocations.
@@ -60,7 +60,7 @@ The stateful functions themselves can be deployed in various
ways that trade off
#### Remote Functions
-*Remote Functions* use the above-mentioned principle of *physical separation*
while maintaining *logical co-location*. The state/messaging tier (i.e., the
Flink processes) and the function tier are deployed, managed, and scaled
independently.
+*Remote Functions* use the above-mentioned principle of *physical separation*
while maintaining *logical co-location*. The state/messaging tier (i.e., the
Flink processes), and the function tier are deployed, managed, and scaled
independently.
Function invocations happen through an HTTP / gRPC protocol and go through a
service that routes invocation requests to any available endpoint, for example
a Kubernetes (load-balancing) service, the AWS request gateway for Lambda, etc.
Because invocations are self-contained (contain message, state, access to
timers, etc.) the target functions can be treated like any stateless
application.
diff --git a/docs/content/docs/concepts/logical.md
b/docs/content/docs/concepts/logical.md
index 20f08f4..babf3f9 100644
--- a/docs/content/docs/concepts/logical.md
+++ b/docs/content/docs/concepts/logical.md
@@ -28,7 +28,7 @@ under the License.
Stateful Function's are allocated logically, which means the system can
support an unbounded number of instances with a finite amount of resources.
Logical instances do not use CPU, memory, or threads when not actively being
invoked, so there is no theoretical upper limit on the number of instances that
can created.
-Users are encouraged to model their applications as granularly as possible,
based on what makes the most sense for their application, instead of desigining
applications around resource constraints.
+Users are encouraged to model their applications as granularly as possible,
based on what makes the most sense for their application, instead of designing
applications around resource constraints.
@@ -40,11 +40,11 @@ Instead, an ``Address`` is used to reference a specific
stateful function in the
{{< img width="80%" src="/fig/concepts/address.svg" >}}
-An address is made of two components, a ``FunctionType`` and ``ID``.
+An address consists of two components, a ``FunctionType`` and ``ID``.
A function type is similar to a class in an object-oriented language; it
declares what sort of function the address references.
The ID is a primary key, which scopes the function call to a specific instance
of the function type.
-When a function is being invoked, all actions - including reads and writes of
persisted states - are scoped to the current address.
+When a function is invoked, all actions - including reads and writes of
persisted states - are scoped to the current address.
For example, imagine there was a Stateful Functions application to track the
inventory of a warehouse.
One possible implementation could include an ``Inventory`` function that
tracks the number units in stock for a particular item; this would be the
function type.
