github.com/wmuizelaar/kpt@v0.0.0-20221018115725-bd564717b2ed/site/book/05-developing-functions/00.md (about)

     1  [Chapter 2] provided a high-level conceptual explanation of functions. We
     2  discussed how this architecture enables us to develop functions in different
     3  languages, frameworks and runtimes. In this chapter, we are going to look at
     4  different approaches to developing functions.
     5  
     6  ?> Before you start developing your custom function, check out the
     7  [Functions Catalog](https://catalog.kpt.dev/ ":target=_self") in case there is
     8  an existing function that meets your needs. This is an ever-growing catalog of
     9  functions that we consider to be generally useful to many users. If your use
    10  case fits that description, please [open a feature request][fr] for adding a
    11  function to the catalog.
    12  
    13  ## Approaches
    14  
    15  ### Creating Custom Images
    16  
    17  With this approach you create a custom container image which can execute
    18  programs in an arbitrary language or encapsulate existing tools as long as it
    19  satisfies the KRM Functions Specification we will see later in this chapter.
    20  
    21  To simplify development, we provide frameworks for developing functions in Go
    22  and Typescript. We will cover these later in this chapter.
    23  
    24  ### Authoring Executable Configuration
    25  
    26  Instead of developing a custom image, you can use an existing function image
    27  containing a language interpreter, and provide your business logic in a KRM
    28  resource. This is referred to as _executable configuration_. We will see two
    29  examples of executable configuration pattern in this chapter.
    30  
    31  Although using executable configuration saves some time initially, it can become
    32  an anti-pattern if it grows in complexity. We recommend limiting their use to:
    33  
    34  - Small amount of logic (< 20 lines)
    35  - You do not forsee this logic growing in complexity in the future
    36  
    37  Otherwise, you are better off developing functions in a general-purpose language
    38  where you can take advantage of proper abstractions and language features,
    39  better testing, rich IDE experience, and existing libraries.
    40  
    41  ## Function Properties
    42  
    43  As you think about how to formulate your function, keep in mind the following
    44  desired properties:
    45  
    46  ### Deterministic
    47  
    48  Executing a function with the same input should produce the same output. For
    49  example, a function that annotates a resource with the current timestamp is not
    50  deterministic.
    51  
    52  Note that input to the function includes both `input items` and the
    53  `functionConfig`:
    54  
    55  ![img](/static/images/func.svg)
    56  
    57  ### Idempotent
    58  
    59  Executing a function a second time should not produce any change. For example, a
    60  function that increments value of the `replicas` field by 1 is not idempotent.
    61  Instead, the function could take the desired value of the `replicas` field as
    62  input.
    63  
    64  This property enables in-place edits to work and is analogous to the
    65  level-driven reconciliation model of the Kubernetes system.
    66  
    67  ### Hermetic and Unprivileged
    68  
    69  If possible, try to formulate your function to be hermetic. We discussed this in
    70  detail in [chapter 4].
    71  
    72  [chapter 2]: /book/02-concepts/03-functions
    73  [chapter 4]:
    74    /book/04-using-functions/02-imperative-function-execution?id=privileged-execution
    75  [fr]:
    76    https://github.com/GoogleContainerTools/kpt/issues/new?assignees=&labels=enhancement&template=feature_request.md&title=
    77  [functions specification]:
    78    /book/05-developing-functions/01-functions-specification