initial commit

Author: bachuv

articles/azure-functions/durable/durable-functions-best-practice-reference.md

@@ -55,6 +55,8 @@ You can run into memory issues if you provide large inputs and outputs to and fr
 
 Inputs and outputs to Durable Functions APIs are serialized into the orchestration history. This means that large inputs and outputs can, over time, greatly contribute to an orchestrator history growing unbounded, which risks causing memory exceptions during [replay](durable-functions-orchestrations.md#reliability).
 
+Activity functions returning complex API responses (such as Microsoft Graph result sets) can cause extreme memory usage during serialization. Selecting only required fields and returning a simple DTO avoids this issue.
+
 To mitigate the impact of large inputs and outputs to APIs, you may choose to delegate some work to sub-orchestrators. This helps load balance the history memory burden from a single orchestrator to multiple ones, therefore keeping the memory footprint of individual histories small.
 
 That said the best practice for dealing with _large_ data is to keep it in external storage and to only materialize that data inside Activities, when needed. When taking this approach, instead of communicating the data itself as inputs and/or outputs of Durable Functions APIs, you can pass in some lightweight identifier that allows you to retrieve that data from external storage when needed in your Activities.