|
4 | 4 |
|
5 | 5 | - [Abstract](#abstract)
|
6 | 6 | - [Motivation](#motivation)
|
| 7 | +- [Priority of Constituencies](#priority-of-constituencies) |
7 | 8 | - [Design](#design)
|
8 | 9 | - [Concepts](#concepts)
|
9 | 10 | + [Workflow](#workflow)
|
@@ -40,6 +41,23 @@ Serverless computing has gained popularity for its ability to abstract away infr
|
40 | 41 |
|
41 | 42 | Serverless Workflow addresses this challenge by providing a DSL specifically designed for serverless workflow orchestration. By abstracting away the underlying infrastructure complexities and offering a modular and extensible framework, Serverless Workflow aims to streamline the development, deployment, and management of serverless workflows.
|
42 | 43 |
|
| 44 | +## Priority of Constituencies |
| 45 | + |
| 46 | +Inspired by the [Priority of Constituencies](https://www.w3.org/TR/2024/NOTE-design-principles-20240718/#priority-of-constituencies) principle from the W3C Design Principles, the Serverless Workflow DSL prioritizes the following constituencies (collectively referred to as "users"): |
| 47 | + |
| 48 | +- Authors: people authoring and reading workflows |
| 49 | +- Operators: people running and operating a runtime implementation of the specification |
| 50 | +- Implementors: people implementing a specification compliant runtime |
| 51 | +- Specifications writers: people working on the specifications of Serverless Workflow |
| 52 | + |
| 53 | +If a trade-off needs to be made, always put author's needs above all. |
| 54 | + |
| 55 | +Similarly, when beginning to design an API, be sure to understand and document the user needs that the API aims to address. |
| 56 | + |
| 57 | +Author needs come before the needs of operators, which come before the needs of runtime implementors, which come before the needs of specification writers, which come before theoretical purity. |
| 58 | + |
| 59 | +Like all principles, this isn’t absolute. Ease of operations affects the perceived reliability of authors' workflows. Implementors have to prioritize finite engineering resources, which affects how features reach authors. Specification writers also have finite resources, and theoretical concerns reflect the underlying needs of all of these groups. |
| 60 | + |
43 | 61 | ## Design
|
44 | 62 |
|
45 | 63 | The Serverless Workflow DSL is crafted with a design philosophy that prioritizes clarity, expressiveness, and ease of use. Its foundation lies in linguistic fluency, emphasizing readability and comprehension. By adopting a fluent style, the DSL promotes intuitive understanding through natural language constructs. Verbs are employed in the imperative tense to denote actions, enhancing clarity and directness in expressing workflow logic. This imperative approach empowers developers to articulate their intentions succinctly and effectively.
|
|
0 commit comments