Merge branch 'subgraph-best-practice-5-6' of https://github.com/graph…

…protocol/docs into subgraph-best-practice-5-6

website/pages/en/cookbook/derivedfrom.mdx

@@ -68,9 +68,9 @@ This will not only make our subgraph more efficient, but it will also unlock thr
 
 ## Conclusion
 
-Adopting the `@derivedFrom` directive in subgraphs effectively handles dynamically growing arrays, enhancing indexing efficiency and data retrieval.
+Use the `@derivedFrom` directive in subgraphs to effectively manage dynamically growing arrays, enhancing indexing efficiency and data retrieval.
 
-To learn more detailed strategies to avoid large arrays, read this blog from Kevin Jones: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
+For a more detailed explanation of strategies to avoid large arrays, check out Kevin Jones' blog: [Best Practices in Subgraph Development: Avoiding Large Arrays](https://thegraph.com/blog/improve-subgraph-performance-avoiding-large-arrays/).
 
 ## Subgraph Best Practices 1-6
 

website/pages/en/cookbook/grafting-hotfix.mdx

@@ -4,9 +4,15 @@ Subgraph Best Practice 6 - Use Grafting for Quick Hotfix Deployment
 
 ## TLDR
 
-Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones. This technique is particularly useful for quickly deploying hotfixes to address critical issues without the need to re-index the entire subgraph from scratch. By preserving historical data, grafting ensures minimal downtime and maintains continuity in data services.
+## TLDR
+
+Grafting is a powerful feature in subgraph development that allows you to build and deploy new subgraphs while reusing the indexed data from existing ones. 
+
+### Overview
+
+This feature enables quick deployment of hotfixes for critical issues, eliminating the need to re-index the entire subgraph from scratch. By preserving historical data, grafting minimizes downtime and ensures continuity in data services.
 
-## Why Grafting Is a Best Practice for Hotfixes
+## Benefits of Grafting for Hotfixes 
 
 1. **Rapid Deployment**
 
@@ -40,7 +46,7 @@ Grafting is a powerful feature in subgraph development that allows you to build
 
    - **Monitor Performance**: Ensure the grafted subgraph is indexing correctly and the hotfix resolves the issue.
    - **Republish Without Grafting**: Once stable, deploy a new version of the subgraph without grafting for long-term maintenance.
-   - **Reason**: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
+   > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
    - **Update References**: Redirect any services or applications to use the new, non-grafted subgraph.
 
 4. **Important Considerations**
@@ -127,7 +133,7 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
 3. **Deployment Steps**
 
    - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
-   - **Adjust the Manifest**: As shown above, update the subgraph.yaml with grafting configurations.
+   - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
    - **Deploy the Subgraph**:
      - Authenticate with the Graph CLI.
      - Deploy the new subgraph using `graph deploy`.
@@ -137,15 +143,14 @@ Suppose you have a subgraph tracking a smart contract that has stopped indexing
    - **Monitor Data**: Ensure that new data is being captured and the hotfix is effective.
    - **Plan for Republish**: Schedule the deployment of a non-grafted version for long-term stability.
 
-## Key Considerations
+## Warnings and Cautions 
 
-### When Not to Use Grafting
 
 While grafting is a powerful tool for deploying hotfixes quickly, there are specific scenarios where it should be avoided to maintain data integrity and ensure optimal performance.
 
 - **Incompatible Schema Changes**: If your hotfix requires altering the type of existing fields or removing fields from your schema, grafting is not suitable. Grafting expects the new subgraph’s schema to be compatible with the base subgraph’s schema. Incompatible changes can lead to data inconsistencies and errors because the existing data won’t align with the new schema.
 - **Significant Mapping Logic Overhauls**: When the hotfix involves substantial modifications to your mapping logic—such as changing how events are processed or altering handler functions—grafting may not function correctly. The new logic might not be compatible with the data processed under the old logic, leading to incorrect data or failed indexing.
-- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
+- **Deployments to The Graph Network**: Grafting is not recommended for subgraphs intended for The Graph’s decentralized network (mainnet). It can complicate indexing and may not be fully supported by all Indexers, potentially causing unexpected behavior or increased costs. For mainnet deployments, it’s safer to re-index the subgraph from scratch to ensure full compatibility and reliability.
 
 ### Risk Management
 
@@ -165,7 +170,7 @@ However, it’s important to use grafting judiciously and follow best practices
 ## Additional Resources
 
 - **[Grafting Documentation](/cookbook/grafting/)**: Replace a Contract and Keep its History With Grafting
-- **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID in The Graph’s documentation.
+- **[Understanding Deployment IDs](/querying/querying-by-subgraph-id-vs-deployment-id/)**: Learn the difference between Deployment ID and Subgraph ID.
 
 By incorporating grafting into your subgraph development workflow, you can enhance your ability to respond to issues swiftly, ensuring that your data services remain robust and reliable.
 

website/pages/en/cookbook/timeseries.mdx

@@ -4,9 +4,13 @@ title: Subgraph Best Practice 5 - Simplify and Optimize with Timeseries and Aggr
 
 ## TLDR
 
-Leveraging the new timeseries and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance. By offloading aggregation computations to the database and simplifying mapping code, this approach reduces data processing overhead and accelerates queries, especially when dealing with large volumes of time-based data.
+Leveraging the new time-series and aggregations feature in subgraphs can significantly enhance both indexing speed and query performance. 
 
-## Why Timeseries and Aggregations Are a Best Practice
+## Overview
+
+Timeseries and aggregations reduce data processing overhead and accelerate queries by offloading aggregation computations to the database and simplifying mapping code. This approach is particularly effective when handling large volumes of time-based data.
+
+## Benefits of Timeseries and Aggregations
 
 1. Improved Indexing Time
   - Less Data to Load: Mappings handle less data since raw data points are stored as immutable timeseries entities.