Merge pull request #224 from latchbio/ayush/secrets

docs/source/basics/adding_secrets.md

@@ -0,0 +1,55 @@
+# Storing and using Secrets
+
+Often a workflow can depend on _secret data_, such as an API key, to function
+correctly. To make storing and using secret data easy, the Latch SDK comes with
+special utilities that handle this securely.
+
+## Adding Secrets
+
+To add a secret, simply navigate to the [Latch Console](https://console.latch.bio)
+and head to Account Settings > Developer Settings.
+
+![How to get to Account Settings](../assets/settings-menu.png)
+
+![How to get to Developer Settings](../assets/developer-settings.png)
+
+From there, scroll down to the 'Secrets' section and add your secrets. Secrets
+consist of key-value pairs where keys are unique across a workspace. Secrets are
+also immutable, so the only way to change the value of a given secret is to
+delete it and add a new one with the same key.
+
+## Using Secrets
+
+To use a secret in a workflow, simply use the `get_secret` function built into
+the Latch SDK. This function takes in a key and returns the value of the secret
+with that key as a string. When run locally, secrets are looked up in the user's
+personal workspace only (for security reasons). When running a workflow in the
+console, secrets are looked up in the workspace in which the workflow was
+registered. Moreover, such workflows will only succeed if ran in the registered
+workspace, meaning that no one outside of your team will be able to access your
+secrets.
+
+As an example, the following task will get the value of the secret `API_KEY` and
+use it to send a request to a server.
+
+```python
+from latch import small_task
+from latch.functions.secrets import get_secret
+import requests
+
+
+@small_task
+def send_fake_data_task(fake_data: str) -> bool:
+    token = get_secret("API_KEY")
+
+    response = requests.post(
+        "https://fake.example.com/fake/endpoint",
+        headers={"Authorization": f"Bearer {token}"}
+        json={
+            "fake_data": fake_data
+        }
+    )
+
+    return response.status_code == 200
+
+```

docs/source/basics/caching.md

@@ -41,7 +41,7 @@ def do_sleep_with_version(foo: str) -> str:
 
 Each task maintains its own cache that is independent from whatever workflow it
 happens to be associated with.  This allows tasks to preserve their cache
-across workflow re-registers if other tasks are modified. 
+across workflow re-registers if other tasks are modified.
 
 Examples of when a task's cache will get invalidated:
 
@@ -63,8 +63,8 @@ A task's cache will be invalidated and the task will be run from scratch if any
 of the following change between executions:
 
 * the account to which the task is registered, including:
-    * individual user accounts
-    * workspaces owned by the same user
+  * individual user accounts
+  * workspaces owned by the same user
 * the name of the task (name of the function)
 * the function signature of the task (name and typing of all input / output
   parameters)

docs/source/basics/draft.md

@@ -52,7 +52,7 @@ as another task we can assume was defined elsewhere, `sort_bam_task`.
 You must not write actual logic in the workflow function body. It can only be
 used to call task functions and pass task function return values to downstream
 task functions. Additionally all task functions must be called with keyword
-arguments. You also cannot access variables directly in the workflow function; 
+arguments. You also cannot access variables directly in the workflow function;
 in the example below, you would not be able to pass in `read1=read1.local_path`.
 
 ```python
@@ -308,4 +308,4 @@ The registration process requires a local installation of Docker.
 
 To re-register changes, make sure you update the value in the version file. (The
 value of the version is not important, only that it is distinct from previously
-registered versions).
+registered versions).