paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 48 Packages Projects Releases Wiki Activity

fix links

Browse Source 
Signed-off-by: Fredrik Adelöw <freben@gmail.com>
This commit is contained in:
Fredrik Adelöw
2023-12-12 12:59:19 +01:00
parent 6aa0cda977
commit 716061d7ba
4 changed files with 11 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/frontend-system/architecture/06-utility-apis.md
+6 -24
View File
@@ -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)
docs/frontend-system/utility-apis/01-index.md
+1 -1
View File
@@ -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.