From 716061d7bad05c3e59e20e629a6daaf3dc06a359 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fredrik=20Adel=C3=B6w?= Date: Tue, 12 Dec 2023 12:59:19 +0100 Subject: [PATCH] fix links MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Fredrik Adelöw --- docs/backend-system/architecture/01-index.md | 2 +- .../architecture/06-utility-apis.md | 30 ++++--------------- docs/frontend-system/utility-apis/01-index.md | 2 +- docs/getting-started/configuration.md | 6 ++-- 4 files changed, 11 insertions(+), 29 deletions(-) diff --git a/docs/backend-system/architecture/01-index.md b/docs/backend-system/architecture/01-index.md index 0e780039b6..6f1a3dd4d1 100644 --- a/docs/backend-system/architecture/01-index.md +++ b/docs/backend-system/architecture/01-index.md @@ -59,7 +59,7 @@ Just like plugins, modules also have access to services and can depend on their A detailed explanation of the package architecture can be found in the [Backstage Architecture -Overview](../../overview/architecture-overview/#package-architecture). The +Overview](../../overview/architecture-overview.md#package-architecture). The most important packages to consider for this system are the following: - `plugin--backend` houses the implementation of the backend plugins diff --git a/docs/frontend-system/architecture/06-utility-apis.md b/docs/frontend-system/architecture/06-utility-apis.md index 4fbbf1af94..bacdcefce2 100644 --- a/docs/frontend-system/architecture/06-utility-apis.md +++ b/docs/frontend-system/architecture/06-utility-apis.md @@ -10,39 +10,21 @@ description: Utility APIs ## Overview -Utility APIs are pieces of standalone functionality, interfaces that can be -requested by plugins to use. They are defined by a TypeScript interface as well -as a reference (an "API ref") used to access its implementation. They can be -provided both by plugins and the core framework, and are themselves -[extensions](../architecture/03-extensions.md) that can have inputs, be -replaced, and be declaratively configured in your app-config. +Utility APIs are pieces of standalone functionality, interfaces that can be requested by plugins to use. They are defined by a TypeScript interface as well as a reference (an "API ref") used to access its implementation. They can be provided both by plugins and the core framework, and are themselves [extensions](../architecture/03-extensions.md) that can have inputs, be replaced, and be declaratively configured in your app-config. -A common example of a utility API is a client interface to interact with the -backend part of a plugin, such as the catalog client. Any frontend plugin can -then request an implementation of that interface to make requests through. +A common example of a utility API is a client interface to interact with the backend part of a plugin, such as the catalog client. Any frontend plugin can then request an implementation of that interface to make requests through. -The following diagram shows a hypothetical application, which depends on two -plugins and also provides some extra overrides. Note that both the plugins and -the core framework exposed utility APIs, and that they depended on each other. -The app also chose to use its overrides mechanism to supply a replacement -implementation of one API, which took precedence over the default one. Thus, all -consumers of that API will be sure to get that new implementation provided to -them. +The following diagram shows a hypothetical application, which depends on two plugins and also provides some extra overrides. Note that both the plugins and the core framework exposed utility APIs, and that they depended on each other. The app also chose to use its overrides mechanism to supply a replacement implementation of one API, which took precedence over the default one. Thus, all consumers of that API will be sure to get that new implementation provided to them. ![frontend system utility apis diagram](../../assets/frontend-system/architecture-utility-apis.drawio.svg) ## Extension structure -All utility APIs implement the `coreExtensionData.apiFactory` output data type, -and must attach exclusively to the `core` extension's `apis` input no matter who -provided them. These defaults are provided out of the box by the -`createApiExtension` framework function. +All utility APIs implement the `coreExtensionData.apiFactory` output data type, and must attach exclusively to the `core` extension's `apis` input no matter who provided them. These defaults are provided out of the box by the `createApiExtension` framework function. -Since utility APIs are extensions, they can also have inputs in advanced use -cases. This is occasionally useful for complex APIs that can themselves be -extended with additional programmatic functionality by adopters. +Since utility APIs are extensions, they can also have inputs in advanced use cases. This is occasionally useful for complex APIs that can themselves be extended with additional programmatic functionality by adopters. ## Links -- The [Using Utility APIs section](../building-plugins/03-utility-apis.md) of the plugin docs +- The [Utility APIs section](../utility-apis/01-index.md) of the plugin docs - The legacy docs on [utility APIs](../../api/utility-apis.md) diff --git a/docs/frontend-system/utility-apis/01-index.md b/docs/frontend-system/utility-apis/01-index.md index 353ad3ffe4..b6eb22706d 100644 --- a/docs/frontend-system/utility-apis/01-index.md +++ b/docs/frontend-system/utility-apis/01-index.md @@ -12,7 +12,7 @@ As described [in the architecture section](../architecture/06-utility-apis.md), > For details, [see the main article](./02-creating.md). -Backstage apps, the core Backstage framework, and plugins can all expose utility APIs for general use. +Backstage apps, plugins, and the core Backstage framework can all expose utility APIs for general use. Some are available out of the box, such as the API for reading app configuration. Some are provided by third party plugins, such as the catalog client API that both the catalog itself and your own code can leverage to talk to the catalog backend. Some, you may create yourself and make available inside your Backstage instance for use within your private ecosystem of plugins. diff --git a/docs/getting-started/configuration.md b/docs/getting-started/configuration.md index b7bf7d448d..019ca254bb 100644 --- a/docs/getting-started/configuration.md +++ b/docs/getting-started/configuration.md @@ -134,7 +134,7 @@ links: There are multiple authentication providers available for you to use with Backstage, feel free to follow -[the instructions for adding authentication](../auth/). +[the instructions for adding authentication](../auth/index.md). For this tutorial we choose to use GitHub, a free service most of you might be familiar with. For other options, see @@ -205,7 +205,7 @@ Restart Backstage from the terminal, by stopping it with `Control-C`, and starti To learn more about Authentication in Backstage, here are some docs you could read: -- [Authentication in Backstage](../auth/) +- [Authentication in Backstage](../auth/index.md) - [Using organizational data from GitHub](../integrations/github/org.md) ### Setting up a GitHub Integration @@ -254,7 +254,7 @@ integrations: Some helpful links, for if you want to learn more about: -- [Other available integrations](../integrations/) +- [Other available integrations](../integrations/index.md) - [Using GitHub Apps instead of a Personal Access Token](../integrations/github/github-apps.md#docsNav) ### Explore what we've done so far