Path: blob/master/site/en-snapshot/federated/program/guide.md
25118 views
Federated Program Developer Guide
This documentation is for anyone who is interested in authoring federated program logic or a federated program. It assumes knowledge of TensorFlow Federated, especially its type system, and federated programs.
[TOC]
Program Logic
This section defines guidelines for how program logic should be authored.
See the example program_logic.py for more information.
Document Type Signatures
Do document the TFF type signature for each parameter supplied to the program logic that has a type signature.
Check Type Signatures
Do check the TFF type signature (at runtime) for each parameter supplied to the program logic that has a type signature.
Type Annotations
Do provide a well defined Python type for each tff.program.ReleaseManager
parameter supplied to the program logic.
Not
Program State
Do provide a well defined structure describing the program state of the program logic.
Document Released Values
Do document the values released from the program logic.
Release Specific Values
Do not release more values from the program logic than is required.
Not
Note: It is ok to release all the values if that is what is required.
Asynchronous Functions
Do define the program logic as an asynchronous function. The components of TFF's federated program library use asyncio to execute Python concurrently and defining the program logic as an asynchronous function makes it easier to interact with those components.
Not
Tests
Do provide unit tests for the program logic (e.g. program_logic_test.py).
Program
This section defines guidelines for how a program should be authored.
See the example program.py for more information.
Document the Program
Do document the details of the program to the customer in the docstring of the module (e.g. program.py):
How to manually run the program.
What platform, computations, and data sources are used in the program.
How a customer should access information released from the program to customer storage.
Too Many Parameters
Don't parameterize the program such that there are mutually exclusive collections of parameters. For example, if foo
is set to X
then you are also required to set parameters bar
, baz
, otherwise these parameters must be None
. This indicates that you could have made two different programs for different values of foo
.
Group Parameters
Do use proto to define related but complex or verbose parameters instead of defining many FLAGS (go/absl.flags).
Note: Proto can be read from disk and used to construct Python objects, for example:
Python Logic
Don't write logic (e.g. control flow, invoking computations, anything that needs to be tested) in the program. Instead, move the logic into a private library that can be tested or into the program logic the program invokes.
Asynchronous Functions
Don't write asynchronous functions in the program. Instead, move the function into a private library that can be tested or into the program logic the program invokes.
Tests
Don't write unit tests for the program, if testing the program is useful write those tests in terms of integration tests.
Note: It should be unlikely that testing the program is useful if Python logic and asynchronous functions are moved into libraries and tested.