Docs: More BE/FE sweep (#2076)

Co-authored-by: Andres Martinez Gotor <[email protected]>

Author: urbiz-grafana

docusaurus/docs/get-started/get-started.mdx

@@ -40,7 +40,7 @@ Grafana plugin development allows you to create many different types of user exp
 
 :::tip
 
-If this is your first time creating a plugin, we recommend that you familiarize yourself with the fundamentals of plugin types, frontend and backend plugin components, data frames, and other essentials. Learn more about the [key concepts of Grafana plugin development](/key-concepts/).
+If this is your first time creating a plugin, we recommend that you familiarize yourself with the fundamentals of plugin types, frontend and backend components, data frames, and other essentials. Learn more about the [key concepts of Grafana plugin development](/key-concepts/).
 
 :::
 

docusaurus/docs/how-to-guides/data-source-plugins/add-authentication-for-data-source-plugins.md

@@ -17,8 +17,8 @@ Grafana plugins can perform authenticated requests against a third-party API by
 
 Configure your data source plugin to authenticate against a third-party API in one of either of two ways:
 
-- Use the [_data source proxy_](#authenticate-using-the-data-source-proxy) method, or
-- Build a [_backend plugin_](#authenticate-using-a-backend-plugin).
+- Use the [data source proxy](#authenticate-using-the-data-source-proxy) method, or
+- Build a [plugin backend component](#authenticate-using-a-plugin-backend).
 
 | Case                                                                                            | Use                        |
 | ----------------------------------------------------------------------------------------------- | -------------------------- |
@@ -311,14 +311,14 @@ Be aware that `tokenAuth` configuration is only supported in data source plugins
 
 :::
 
-## Authenticate using a backend plugin
+## Authenticate using a plugin backend 
 
 While the data source proxy supports the most common authentication methods for HTTP APIs, using proxy routes has a few limitations:
 
 - Proxy routes only support HTTP or HTTPS.
 - Proxy routes don't support custom token authentication.
 
-If any of these limitations apply to your plugin, you need to add a [backend plugin](../../key-concepts/backend-plugins/#caching-and-connection-pooling). Because backend plugins run on the server, they can access decrypted secrets, which makes it easier to implement custom authentication methods.
+If any of these limitations apply to your plugin, you need to add a [backend component](../../key-concepts/backend-plugins/#caching-and-connection-pooling). Because plugin backend components run on the server, they can access decrypted secrets, which makes it easier to implement custom authentication methods.
 
 The decrypted secrets are available from the `DecryptedSecureJSONData` field in the instance settings.
 

docusaurus/docs/how-to-guides/data-source-plugins/add-features-for-explore-queries.md

@@ -11,13 +11,13 @@ keywords:
   - explore
 ---
 
-[Explore](https://grafana.com/docs/grafana/latest/explore/) allows users can make ad-hoc queries without the use of a dashboard. This is useful when they want to troubleshoot or learn more about the data.
+[Explore](https://grafana.com/docs/grafana/latest/explore/) allows you to make ad-hoc queries without having to use a dashboard. This is useful when you want to troubleshoot or learn more about the data. Your data source supports Explore by default and uses the existing query editor. 
 
-Your data source supports Explore by default and uses the existing query editor for the data source. This guide explains how to extend functionality for Explore queries in a data source plugin.
+This guide explains how to extend functionality for Explore queries in a data source plugin.
 
 ## Add an Explore-specific query editor
 
-To extend Explore functionality for your data source, define an Explore-specific query editor.
+To extend the Explore functionality for your data source, define an Explore-specific query editor.
 
 1. Create a file `ExploreQueryEditor.tsx` in the `src` directory of your plugin, with content similar to this:
 
@@ -59,7 +59,7 @@ To extend Explore functionality for your data source, define an Explore-specific
 
 ## Select a preferred visualization type
 
-By default, Explore should select an appropriate and useful visualization for your data. It can figure out whether the returned data is time series data or logs or something else, and creates the right type of visualization.
+By default, Explore identifies your returned data (time series, logs, or something else) and creates the right type of visualization.
 
 However, if you want a custom visualization, you can add a hint to your returned data frame by setting the `meta` attribute to `preferredVisualisationType`.
 

docusaurus/docs/how-to-guides/data-source-plugins/add-logs-metrics-traces-for-backend-plugins.md

@@ -1,7 +1,7 @@
 ---
 id: add-logs-metrics-traces-for-backend-plugins
-title: Add logs, metrics, and traces for backend plugins
-description: How to add logs, metrics and traces for backend plugins.
+title: Add logs, metrics, and traces to plugin backends
+description: How to add logs, metrics and traces to plugin backend components.
 keywords:
   - grafana
   - plugins
@@ -16,7 +16,7 @@ keywords:
   - back-end
 ---
 
-Adding [logs](#logs), [metrics](#metrics) and [traces](#traces) for backend plugins makes it easier to diagnose and resolve issues for both plugin developers and Grafana operators. This document provides guidance, conventions and best practices to help you effectively instrument your plugins, as well as how to access this data when the plugin is installed.
+Adding [logs](#logs), [metrics](#metrics) and [traces](#traces) to plugin backend components makes it easier to diagnose and resolve issues for both plugin developers and Grafana operators. This document provides guidance, conventions and best practices to help you effectively instrument your plugins, as well as how to access this data when the plugin is installed.
 
 :::note
 
@@ -255,9 +255,9 @@ Incoming requests of high frequency are normally more common for the `QueryData`
 
 ### Inspect logs locally
 
-Logs from a backend plugin are consumed by the connected Grafana instance and included in the Grafana server log.
+Logs from a plugin's backend are consumed by the connected Grafana instance and included in the Grafana server log.
 
-Each log message for a backend plugin will include a logger name, `logger=plugin.<plugin id>`. Example:
+Each log message from a plugin backend component includes a logger name `logger=plugin.<plugin id>`. For example:
 
 ```shell
 DEBUG[11-14|15:26:26] Debug msg     logger=plugin.grafana-basic-datasource someID=1
@@ -379,13 +379,13 @@ If a value originating from user input are unbounded, that is when the value cou
 
 ### Collect and visualize metrics locally
 
-Please refer to [Pull metrics from Grafana backend plugin into Prometheus](https://grafana.com/docs/grafana/latest/setup-grafana/set-up-grafana-monitoring/#pull-metrics-from-grafana-backend-plugin-into-prometheus).
+Please refer to [Pull metrics from a Grafana plugin backend into Prometheus](https://grafana.com/docs/grafana/latest/setup-grafana/set-up-grafana-monitoring/#pull-metrics-from-grafana-backend-plugin-into-prometheus).
 
 Further, see [How to collect and visualize logs, metrics and traces](#collect-and-visualize-logs-metrics-and-traces).
 
 ## Traces
 
-Distributed tracing allows backend plugin developers to create custom spans in their plugins, and then send them to the same endpoint and with the same propagation format as the main Grafana instance. The tracing context is also propagated from the Grafana instance to the plugin, so the plugin's spans will be correlated to the correct trace.
+Distributed tracing allows plugin backend developers to create custom spans in their plugins, and then send them to the same endpoint and with the same propagation format as the main Grafana instance. The tracing context is also propagated from the Grafana instance to the plugin, so the plugin's spans will be correlated to the correct trace.
 
 ### OpenTelemetry configuration in Grafana
 

docusaurus/docs/how-to-guides/data-source-plugins/add-router.md

@@ -1,7 +1,7 @@
 ---
 id: add-router
-title: Add a router or multiplexer to your plugin
-description: Add a router or multiplexer to your plugin.
+title: Add a router or multiplexer to query different data types
+description: Add a router or multiplexer to your plugin backend to query different data types.
 keywords:
   - grafana
   - plugins
@@ -10,15 +10,15 @@ keywords:
   - multiplexer
 ---
 
-# Add a query router or multiplexer to your data source backend
+# Add a router or multiplexer to query different data types
 
-Normally you implement the `QueryData` method in your plugin's backend for data queries. But what if you need to support different kinds of queries: metrics, logs, and traces, for instance? That’s where the usage of a query _router_ (also known as a _multiplexer_) comes handy.
+The `QueryData` method in your plugin's backend allows you to query one type of data only. To support different kinds of queries (metrics, logs, and traces) you need to implement query router (also known as a _multiplexer_).
 
-The plugin development requirement is that you need to populate the `queryType` property of your query model client-side, see the [`DataQuery`](https://github.com/grafana/grafana/blob/a728e9b4ddb6532b9fa2f916df106e792229e3e0/packages/grafana-data/src/types/query.ts#L47) interface.
+To do so: 
 
-With `queryType` populated in queries and sent to your backend plugin below is an example of how you would use the [`datasource.QueryTypeMux`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend/datasource#QueryTypeMux) to multiplex or route different query types to separate query handlers.
-
-Implemented in this way, each query handler can then `json.Unmarshal` each query JSON field in [`DataQuery`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend#DataQuery) to a certain Go struct as shown in this example:
+1. Populate the `queryType` property of your query model client-side, as shown in the [`DataQuery`](https://github.com/grafana/grafana/blob/a728e9b4ddb6532b9fa2f916df106e792229e3e0/packages/grafana-data/src/types/query.ts#L47) interface.
+1. With `queryType` populated in queries and sent to your plugin backend component, use [`datasource.QueryTypeMux`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend/datasource#QueryTypeMux) to multiplex or route different query types to separate query handlers.
+1. Each query handler can then `json.Unmarshal` each query JSON field in [`DataQuery`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend#DataQuery) to a certain Go struct as shown in this example:
 
 ```go
 package mydatasource
@@ -78,7 +78,7 @@ func (d *MyDatasource) handleQueryFallback(ctx context.Context, req *backend.Que
 
 ## Advanced usage
 
-An example of using [`QueryTypeMux`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend/datasource#QueryTypeMux) can be found for Grafana's built-in TestData data source. Refer to this code for examples of implementation:
+You can find an example of using [`QueryTypeMux`](https://pkg.go.dev/github.com/grafana/grafana-plugin-sdk-go/backend/datasource#QueryTypeMux) in Grafana's built-in TestData data source code:
 
-- [create query type multiplexer](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/testdata.go#L22) and [calls registerScenarios](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/testdata.go#L44)
-- [registerScenarios method](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/scenarios.go#L33) uses a [helper method](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/scenarios.go#L204-L207) to register each query type handler. The latter also shows how you can wrap the actual handler in another handler to apply common functionality or middleware to all handlers. For example, logging and traces. 
+- [Create a query type multiplexer](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/testdata.go#L22) and [call `registerScenarios`](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/testdata.go#L44).
+- The [`registerScenarios` method](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/scenarios.go#L33) uses a [helper method](https://github.com/grafana/grafana/blob/623ee3a2be5c4cd84c61b6bbe82a32d18cc29828/pkg/tsdb/grafana-testdata-datasource/scenarios.go#L204-L207) to register each query type handler. The latter also shows how you can wrap the actual handler in another handler to apply common functionality or middleware to all handlers, for example logging and traces. 

docusaurus/docs/how-to-guides/data-source-plugins/add-support-for-externally-shared-dashboards.md

@@ -19,8 +19,8 @@ Because of this, it's necessary to not pass any frontend-transformed body to the
 :::note
 
 Frontend data sources are not compatible with externally shared dashboards.
-To convert a frontend data source plugin into a backend plugin, refer to
-[convert a frontend data source to backend](./convert-a-frontend-datasource-to-backend).
+To convert a data source plugin frontend component into a backend component, refer to
+[convert a data source frontend into a backend](./convert-a-frontend-datasource-to-backend).
 
 :::
 

docusaurus/docs/how-to-guides/data-source-plugins/profile-backend-plugin.md

@@ -13,8 +13,7 @@ keywords:
   - back-end
 ---
 
-This guide provides instructions for configuring a plugin with a backend to enable certain diagnostics when it starts, generating _profiling data_. Profiling data provides potentially useful information
-for investigating certain performance problems, such as high CPU or memory usage, or when you want to use [continuous profiling](https://grafana.com/oss/pyroscope/).
+This guide provides instructions for configuring a plugin with a backend to enable certain diagnostics when it starts, generating _profiling data_. Profiling data provides potentially useful information to investigate certain performance problems, such as high CPU or memory usage, or when you want to use [continuous profiling](https://grafana.com/oss/pyroscope/).
 
 ## Configure profiling data
 

docusaurus/docs/key-concepts/anatomy-of-a-plugin.md

@@ -28,7 +28,7 @@ This guide walks you through the essential components of a Grafana plugin, and h
 
 ## Before you begin
 
-Before proceeding, we recommend reviewing the [plugin types and usage guide](/key-concepts/plugin-types-usage) to gain a basic understanding of the different types of plugins available.
+Before proceeding, review the [plugin types and usage guide](/key-concepts/plugin-types-usage) to gain a basic understanding of the different types of plugins available.
 
 Each Grafana plugin is composed of several essential components that extend Grafana’s functionality in different ways. First, we’ll explore the core parts of each of the three primary plugin types: apps, data sources, and panels.
 
@@ -169,7 +169,7 @@ The following files are crucial for your plugin's development and functionality:
 - **Frontend code** (`src/`): Required. This directory contains all the frontend code for your plugin. The main files to be aware of here are `plugin.json` and `module.ts`.
   - `plugin.json`: Stores [metadata about your plugin](/reference/plugin-json), including information like its description, supported Grafana versions, and dependencies.
   - `module.ts`: The entry point for your plugin's frontend logic.
-- **Backend code** (`pkg/`): Required if your plugin has a backend component. If your plugin includes backend functionality, the code will reside in this directory, typically within `pkg/plugin/`. Backend plugins are written in Go, and `main.go` serves as the entry point for your backend logic.
+- **Backend code** (`pkg/`): Required if your plugin has a backend component. If your plugin includes backend functionality, the code will reside in this directory, typically within `pkg/plugin/`. Plugin backend components are written in Go, and `main.go` serves as the entry point for your backend logic.
 - **Test files** (`tests/`): Optional, but strongly recommended to ensure plugin quality. This folder contains your plugin’s test files, typically suffixed with `.spec.ts` for frontend tests. You can [learn more about testing your plugin](/e2e-test-a-plugin/index.md) in our E2E testing guide.
 - **Other files**:
   - `docker-compose.yaml`: Required for Docker environment only. Contains the Docker configuration for running a local development instance of Grafana.

docusaurus/docs/key-concepts/backend-plugins/index.md

@@ -19,41 +19,41 @@ Introduced in Grafana v7.0, plugins with backend components allow you to integra
 A plugin with a backend requires a frontend component as well. For example, all data source plugins need a query editor component on the frontend.
 :::
 
-## Benefits for plugin backend development
+## Benefits of plugin backend development
 
-This approach has the following benefits:
+Adding a backend component to your plugin has the following benefits:
 
-- **Stability:** Plugins can't crash your Grafana process: a panic in a plugin doesn't panic the server.
-- **Ease of development:** Grafana provides an officially supported SDK for Go and tooling to help create plugins.
-- **Security:** Plugins only have access to the interfaces and arguments given to them, not to the entire memory space of the process.
+- **Stability**: Plugins can't crash your Grafana process. A panic in a plugin doesn't panic the server.
+- **Ease of development**: Grafana provides an officially supported SDK for Go and tooling to help create plugins.
+- **Security**: Plugins only have access to the interfaces and arguments given to them, not to the entire memory space of the process.
 
 ## When to implement a plugin with a backend
 
-The following examples give some common use cases for plugins with a backend component:
+Here's some common use cases for plugins with a backend component:
 
 - Support [Grafana Alerting](https://grafana.com/docs/grafana/latest/alerting/), [Recorded Queries](https://grafana.com/docs/grafana/latest/administration/recorded-queries/) and [Query and resource caching](https://grafana.com/docs/grafana/latest/administration/data-source-management/#query-and-resource-caching) for data sources.
 - Connect to SQL database servers and other non-HTTP services that normally can't be connected to from a browser.
 - Keep state between users, for example, by implementing custom caching for data sources.
 - Use custom authentication methods and/or authorization checks that aren't supported in Grafana.
 - Use a custom data source request proxy (refer to [Resources](#resources) for more information).
 
-## Capabilities of the plugin backend system
+## Capabilities of the Grafana plugin backend system
 
 Grafana's plugin backend system exposes several key capabilities, or building blocks, that your backend component can implement:
 
-- Query data
-- Resources
-- Health checks
-- Collect metrics
-- Streaming
+- [Query data](#query-data)
+- [Resources](#resources)
+- [Health checks](#health-checks)
+- [Collect metrics](#collect-metrics)
+- [Streaming](#streaming)
 
 ### Query data
 
 The query data capability allows a plugin's backend to handle data source queries that are submitted from a [dashboard](https://grafana.com/docs/grafana/latest/dashboards), [Explore](https://grafana.com/docs/grafana/latest/explore) or [Grafana Alerting](https://grafana.com/docs/grafana/latest/alerting). The response contains [data frames](../data-frames), which are used to visualize metrics, logs, and traces.
 
 :::note
 
-Backend data source plugins are required to implement the query data capability.
+To implement the query data capability you need a data source plugin backend.
 
 :::