Merge pull request #22542 from sennyeya/documentation/glossary
docs: add a central glossary
This commit is contained in:
Fredrik Adelöw
@@ -1,30 +0,0 @@
|
||||
---
|
||||
id: glossary
|
||||
title: Glossary
|
||||
description: All Glossaries related to auth
|
||||
---
|
||||
|
||||
- **Popup** - A separate browser window opened on top of the previous one.
|
||||
- **OAuth** - More specifically OAuth 2.0, a standard protocol for
|
||||
authorization. See [oauth.net/2/](https://oauth.net/2/).
|
||||
- **OpenID Connect** - A layer on top of OAuth which standardises
|
||||
authentication. See
|
||||
[en.wikipedia.org/wiki/OpenID_Connect](https://en.wikipedia.org/wiki/OpenID_Connect).
|
||||
- **JWT** - JSON Web Token, a popular JSON based token format that is commonly
|
||||
encrypted and/or signed, see
|
||||
[en.wikipedia.org/wiki/JSON_Web_Token](https://en.wikipedia.org/wiki/JSON_Web_Token)
|
||||
- **Scope** - A string that describes a certain type of access that can be
|
||||
granted to a user using OAuth.
|
||||
- **Access token** - A token that gives access to perform actions on behalf of a
|
||||
user. It will commonly have a short expiry time, and be limited to a set of
|
||||
scopes. Part of the OAuth protocol.
|
||||
- **ID token** - A JWT used to prove a user's identity, containing for example
|
||||
the user's email. Part of OpenID Connect.
|
||||
- **Offline access** - OAuth flow that results in both a refresh and access
|
||||
token, where the refresh token has a long expiration or never expires, and can
|
||||
be used to request more access tokens in the future. This lets the user go
|
||||
"offline" with respect to the token issuer, but still be able to request more
|
||||
tokens at a later time without further direct interaction for the user.
|
||||
- **Code grant** - OAuth flow where the client receives an authorization code
|
||||
that is passed to the backend to be exchanged for an access token and possibly
|
||||
refresh token.
|
||||
@@ -258,7 +258,7 @@ When building CommonJS or ESM output, the build commands will always use
|
||||
`src/index.ts` as the entrypoint. All non-relative modules imports are considered
|
||||
external, meaning the Rollup build will only compile the source code of the package
|
||||
itself. All import statements of external dependencies, even within the same
|
||||
monorepo, will stay intact.
|
||||
[monorepo](../references/glossary.md#monorepo), will stay intact.
|
||||
|
||||
The build of the type definitions works quite differently. The entrypoint of the
|
||||
type definition build is the relative location of the package within the
|
||||
@@ -307,11 +307,12 @@ support for them instead.
|
||||
|
||||
### Frontend Production
|
||||
|
||||
The frontend production bundling creates your typical web content bundle, all
|
||||
contained within a single folder, ready for static serving. It is used when building
|
||||
packages with the `'frontend'` role, and unlike the development bundling there is no way to
|
||||
build a production bundle of an individual plugin. The output of the bundling
|
||||
process is written to the `dist` folder in the package.
|
||||
The frontend production bundling creates your typical web content
|
||||
[bundle](../references/glossary.md#bundle), all contained within a single
|
||||
folder, ready for static serving. It is used when building packages with the
|
||||
`'frontend'` role, and unlike the development bundling there is no way to
|
||||
build a production bundle of an individual plugin.
|
||||
The output of the bundling process is written to the `dist` folder in the package.
|
||||
|
||||
Just like the development bundling, the production bundling is based on
|
||||
[Webpack](https://webpack.js.org/). It uses the
|
||||
|
||||
@@ -7,11 +7,12 @@ description: Overview of the Backstage CLI
|
||||
## Introduction
|
||||
|
||||
A goal of Backstage is to provide a delightful developer experience in and
|
||||
around the project. Creating new apps and plugins should be simple, iteration
|
||||
around the project. Creating new [apps](../references/glossary.md#app) and
|
||||
[plugins](../references/glossary.md#plugin) should be simple, iteration
|
||||
speed should be fast, and the overhead of maintaining custom tooling should be
|
||||
minimal. As a part of accomplishing this goal, Backstage provides its own build
|
||||
system and tooling, delivered primarily through the
|
||||
[`@backstage/cli`](https://www.npmjs.com/package/@backstage/cli) package. When
|
||||
[`@backstage/cli`](https://www.npmjs.com/package/@backstage/cli) [package](../references/glossary.md#package). When
|
||||
creating an app using
|
||||
[`@backstage/create-app`](https://www.npmjs.com/package/@backstage/create-app),
|
||||
you receive a project that's already prepared with a typical setup and package
|
||||
@@ -36,18 +37,3 @@ The Backstage CLI intentionally does not provide many hooks for overriding or
|
||||
customizing the build process. This is to allow for evolution of the CLI without
|
||||
having to take a wide API surface into account. This allows us to iterate and
|
||||
improve the tooling, as well as to more easily keep the system up to date.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Package** - A package in the Node.js ecosystem, often published to a package
|
||||
registry such as [NPM](https://www.npmjs.com/).
|
||||
- **Monorepo** - A project layout that consists of multiple packages within a
|
||||
single project, where packages are able to have local dependencies on each
|
||||
other. Often enabled through tooling such as [lerna](https://lerna.js.org/)
|
||||
and [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/)
|
||||
- **Local Package** - One of the packages within a monorepo. These package may
|
||||
or may not also be published to a package registry.
|
||||
- **Bundle** - A collection of the deployment artifacts. The output of the
|
||||
bundling process, which brings a collection of packages into a single
|
||||
collection of deployment artifacts.
|
||||
- **Package Role** - The declared role of a package, see [package roles](./cli-build-system.md#package-roles).
|
||||
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
id: glossary
|
||||
title: Backstage Glossary
|
||||
# prettier-ignore
|
||||
description: List of terms, abbreviations, and phrases used in Backstage, together with their explanations.
|
||||
---
|
||||
|
||||
The Backstage Glossary lists terms, abbreviations, and phrases used in
|
||||
Backstage, together with their explanations. We encourage you to use the
|
||||
terminology below for clarity and consistency when discussing Backstage.
|
||||
|
||||
See also [Authentication Glossary](../auth/glossary.md), a separate glossary of terms and phrases
|
||||
specifically related to the authentication and identity section of Backstage.
|
||||
|
||||
### Backstage User Profiles
|
||||
|
||||
There are three main user profiles for Backstage: the integrator, the
|
||||
contributor, and the end user (typically a software engineer).
|
||||
|
||||
| Term | Explanation |
|
||||
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Integrator | The **integrator** hosts the Backstage app and configures which plugins are available to use in the app. |
|
||||
| Contributor | The **contributor** adds functionality to the app by writing plugins. |
|
||||
| End user | The **end user** uses the app's functionality and interacts with its plugins. This profile covers the various roles that help deliver software. The typical end user is a **software engineer**, but users might also consider themselves _designers_, _data scientists_, _product owners_, _engineering managers_, _technical writers_, and so on. |
|
||||
| Software engineer | The **software engineer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and documenting code. This user is more likely to embed documentation in the code files they produce, and create rough drafts of conceptual pages in collaboration with a **technical writer** or _technical editor_. |
|
||||
| Technical writer | The **technical writer** is an **end user** who uses the app's functionality and interacts with its plugins in the course of writing and editing documentation. This user is more likely to produce and customize templates and produce conceptual pages to supplement documentation embedded in code files. |
|
||||
@@ -6,11 +6,11 @@ description: A list of important permission framework concepts
|
||||
|
||||
### Permission
|
||||
|
||||
Any action that a user performs within Backstage may be represented as a permission. More complex actions, like executing a software template, may require authorization for multiple permissions throughout the flow. Permissions are identified by a unique name and optionally include a set of attributes that describe the corresponding action. Plugins are responsible for defining and exposing the permissions they enforce.
|
||||
Any action that a user performs within Backstage may be represented as a permission. More complex actions, like executing a [software template](../references/glossary.md#software-templates), may require [authorization](../references/glossary.md#authorization) for multiple permissions throughout the flow. Permissions are identified by a unique name and optionally include a set of attributes that describe the corresponding action. [Plugins](../references/glossary.md#plugin) are responsible for defining and exposing the permissions they enforce as well as enforcing restrictions from the permission framework.
|
||||
|
||||
### Policy
|
||||
|
||||
User permissions are authorized by a central, user-defined permission policy. At a high level, a policy is a function that receives a Backstage user and permission, and returns a decision to allow or deny. Policies are expressed as code, which decouples the framework from any particular authorization model, like role-based access control (RBAC) or attribute-based access control (ABAC).
|
||||
User [permissions](../references/glossary.md#permission-permission-plugin) are authorized by a central, user-defined permission policy. At a high level, a policy is a function that receives a Backstage user and permission, and returns a decision to allow or deny. Policies are expressed as code, which decouples the framework from any particular [authorization](../references/glossary.md#authorization) model, like role-based access control (RBAC) or attribute-based access control (ABAC).
|
||||
|
||||
### Policy decision versus enforcement
|
||||
|
||||
@@ -18,8 +18,10 @@ Two important responsibilities of any authorization system are to decide if a us
|
||||
|
||||
### Resources and rules
|
||||
|
||||
In many cases, a permission represents a user's interaction with another object. This object likely has information that policy authors can use to define more granular access. The permission framework introduces two abstractions to account for this: resources and rules. Resources represent the objects that users interact with. Rules are predicate-based controls that tap into a resource's data. For example, the catalog plugin defines a resource for catalog entities and a rule to check if an entity has a given annotation.
|
||||
In many cases, a permission represents a user's interaction with another object. This object likely has information that policy authors can use to define more granular access. The permission framework introduces two abstractions to account for this: [resources](../references/glossary.md#resource-permission-plugin) and [rules](../references/glossary.md#rule-permission-plugin). For example, the catalog plugin defines a resource for catalog entities and a rule to check if an entity has a given annotation.
|
||||
|
||||
### Conditional decisions
|
||||
|
||||
Rules need additional data before they can be used in a decision. For example, the catalog plugin's "has annotation" rule needs to know what annotation to look for on a given entity. Once a rule is bound to relevant information it forms a condition. Conditions are then used to return a conditional decision from a policy. Conditional decisions tell the permission framework to delegate evaluation to the plugin that owns the corresponding resource. Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
|
||||
[Rules](../references/glossary.md#rule-permission-plugin) need additional data before they can be used in a decision. Once a [rule](../references/glossary.md#rule-permission-plugin) is bound to relevant information it forms a [condition](../references/glossary.md#condition-permission-plugin). Conditional decisions tell the [permission framework](#permission) to delegate evaluation to the [plugin](#plugin) that owns the corresponding [resource](#resource-permission-plugin). Permission requests that result in a conditional decision are allowed if all of the provided conditions evaluate to be true.
|
||||
|
||||
A good example would be the catalog plugin's "has annotation" rule which needs to know what annotation to look for on a given entity. The permission framework would respond to a request by the catalog plugin in this case with a condition decision. The catalog plugin would then need to correctly filter for entities matching the "has annotations" condition. This conditional behavior avoids coupling between policies and resource schemas, and allows plugins to evaluate complex rules in an efficient way. For example, a plugin may convert a conditional decision to a database query instead of loading and filtering objects in memory.
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Defining custom permission rules
|
||||
description: How to define custom permission rules for existing resources
|
||||
---
|
||||
|
||||
For some use cases, you may want to define custom [rules](./concepts.md#resources-and-rules) in addition to the ones provided by a plugin. In the [previous section](./writing-a-policy.md) we used the `isEntityOwner` rule to control access for catalog entities. Let's extend this policy with a custom rule that checks what [system](https://backstage.io/docs/features/software-catalog/system-model#system) an entity is part of.
|
||||
For some use cases, you may want to define custom [rules](../references/glossary.md#rule-permission-plugin) in addition to the ones provided by a plugin. In the [previous section](./writing-a-policy.md) we used the `isEntityOwner` rule to control access for catalog entities. Let's extend this policy with a custom rule that checks what [system](https://backstage.io/docs/features/software-catalog/system-model#system) an entity is part of.
|
||||
|
||||
## Define a custom rule
|
||||
|
||||
|
||||
@@ -4,9 +4,9 @@ title: 2. Adding a basic permission check
|
||||
description: Explains how to add a basic permission check to a Backstage plugin
|
||||
---
|
||||
|
||||
If the outcome of a permission check doesn't need to change for different [resources](../concepts.md#resources-and-rules), you can use a _basic permission check_. For this kind of check, we simply need to define a [permission](../concepts.md#resources-and-rules), and call `authorize` with it.
|
||||
If the outcome of a permission check doesn't need to change for different [resources](../../references/glossary.md#resource-permission-plugin), you can use a _basic permission check_. For this kind of check, we simply need to define a permission, and call `authorize` with it.
|
||||
|
||||
For this tutorial, we'll use a basic permission check to authorize the `create` endpoint in our todo-backend. This will allow Backstage integrators to control whether each of their users is authorized to create todos by adjusting their [permission policy](../concepts.md#policy).
|
||||
For this tutorial, we'll use a basic permission check to authorize the `create` endpoint in our todo-backend. This will allow Backstage integrators to control whether each of their users is authorized to create todos by adjusting their [permission policy](../../references/glossary.md#policy-permission-plugin).
|
||||
|
||||
We'll start by creating a new permission, and then we'll use the permission api to call `authorize` with it during todo creation.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ title: 3. Adding a resource permission check
|
||||
description: Explains how to add a resource permission check to a Backstage plugin
|
||||
---
|
||||
|
||||
When performing updates (or other operations) on specific [resources](../concepts.md#resources-and-rules), the permissions framework allows for the decision to be based on characteristics of the resource itself. This means that it's possible to write policies that (for example) allow the operation for users that own a resource, and deny the operation otherwise.
|
||||
When performing updates (or other operations) on specific [resources](../../references/glossary.md#resource-permission-plugin), the permissions framework allows for the decision to be based on characteristics of the resource itself. This means that it's possible to write policies that (for example) allow the operation for users that own a resource, and deny the operation otherwise.
|
||||
|
||||
## Creating the update permission
|
||||
|
||||
|
||||
@@ -0,0 +1,314 @@
|
||||
---
|
||||
id: glossary
|
||||
title: Glossary
|
||||
# prettier-ignore
|
||||
description: List of terms, abbreviations, and phrases used in Backstage, together with their explanations.
|
||||
---
|
||||
|
||||
## Access Token
|
||||
|
||||
A [token](#token) that gives access to perform actions on behalf of a user. It will commonly have a short expiry time, and be limited to a set of [scopes](#scope). Part of the [OAuth](#oauth) protocol, see [their docs](https://oauth.net/2/access-tokens/) for more information.
|
||||
|
||||
## Administrator
|
||||
|
||||
Someone responsible for installing and maintaining a Backstage [app](#app) for an organization. A [user role](#user-role).
|
||||
|
||||
## API (catalog plugin)
|
||||
|
||||
An [entity](#entity) representing a schema that two [components](#component) use to communicate. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## App
|
||||
|
||||
An installed instance of Backstage. An app can be local, intended for a single development group or individual developer, or organizational, for use by an entire enterprise.
|
||||
|
||||
## Authorization Code
|
||||
|
||||
A type of [OAuth flow](#oauth) used by confidential and public clients to get an [access token](#access-token). See [the OAuth docs](https://oauth.net/2/grant-types/authorization-code/) for more details.
|
||||
|
||||
## Backstage
|
||||
|
||||
1. A platform for creating and deploying [developer portals](#developer-portal), originally created at Spotify. Backstage is an incubation-stage open source project of the [Cloud Native Computing Foundation](#cloud-native-computing-foundation).
|
||||
|
||||
2. [The Backstage Framework](#backstage-framework).
|
||||
|
||||
## Backstage Framework
|
||||
|
||||
The actual framework that Backstage [plugins](#plugin) sit on. This spans both the frontend and the backend, and includes core functionality such as declarative integration, config reading, database management, and many more.
|
||||
|
||||
## Bundle
|
||||
|
||||
1. A collection of [deployment artifacts](#deployment-artifacts).
|
||||
|
||||
2. The output of the bundling process, which brings a collection of [packages](#package) into a single collection of [deployment artifacts](#deployment-artifacts).
|
||||
|
||||
## Catalog
|
||||
|
||||
1. The core Backstage plugin that handle ingestion and display of your organizations software products.
|
||||
|
||||
2. An organization's portfolio of software products managed in Backstage.
|
||||
|
||||
## Cloud Native Computing
|
||||
|
||||
A set of technologies that "empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach." ([CNCF Cloud Native Definition v1.0](https://github.com/cncf/toc/blob/main/DEFINITION.md)).
|
||||
|
||||
## Cloud Native Computing Foundation
|
||||
|
||||
A foundation dedicated to the promotion and advancement of [Cloud Native Computing](#Cloud-Native-Computing). The mission of the Cloud Native Computing Foundation (CNCF) is "to make cloud native computing ubiquitous" ([CNCF Charter](https://github.com/cncf/foundation/blob/main/charter.md)).
|
||||
|
||||
CNCF is part of the [Linux Foundation](https://www.linuxfoundation.org/).
|
||||
|
||||
## CNCF
|
||||
|
||||
Cloud Native Computing Foundation.
|
||||
|
||||
## Code Grant
|
||||
|
||||
[OAuth](#oauth) flow where the client receives an [authorization code](#code) that is passed to the backend to be exchanged for an [access token](#access-token) and possibly a [refresh token](#refresh-token).
|
||||
|
||||
## Collator (search plugin)
|
||||
|
||||
A transformer that takes streams of [documents](#documents) and outputs searchable texts. They're usually responsible for the data transformation and definition and collection process for specific [documents](#documents).
|
||||
|
||||
## Component (catalog plugin)
|
||||
|
||||
A software product that is managed in the Backstage [Software Catalog](#software-catalog). A component can be a service, website, library, data pipeline, or any other piece of software managed as a single project. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## Condition (permission plugin)
|
||||
|
||||
A mapping from a given entity to criteria a user must fulfill to perform an action on that entity. Examples include `isOwner`, `hasRole`, etc.
|
||||
|
||||
## Conditional Decision (permission plugin)
|
||||
|
||||
A type of [decision](#policy-decision-permission-plugin) that allows for per-user evaluation of [conditions](#condition-permission-plugin) against a [resource](#resource-permission-plugin). See [Conditional Decisions](../permissions/concepts.md#conditional-decisions)
|
||||
|
||||
## Contributor
|
||||
|
||||
A volunteer who helps to improve an OSS product such as Backstage. This volunteer effort includes coding, testing, technical writing, user support, and other work. A [user role](#user-role).
|
||||
|
||||
## Declarative Integration
|
||||
|
||||
A new paradigm for Backstage frontend plugins, allowing definition in config files instead of hosting complete React pages. See [the Frontend System](https://backstage.io/docs/frontend-system).
|
||||
|
||||
## Decorator (search plugin)
|
||||
|
||||
A transform stream that allows you to add additional information to [documents](#document-search-plugin).
|
||||
|
||||
## Deployment Artifacts
|
||||
|
||||
An executable or package file with all of the necessary information required to deploy the application at runtime. Deployment artifacts can be hosted on [package registries](#package-registry).
|
||||
|
||||
## Developer
|
||||
|
||||
1. Someone who writes code and develops software.
|
||||
|
||||
2. A [user role](#user-role) defined as someone who uses a Backstage [app](#app). Might or might not actually be a software developer.
|
||||
|
||||
## Developer Portal
|
||||
|
||||
A centralized system comprising a user interface and database used to facilitate and document all the software projects within an organization. Backstage is both a developer portal and (by virtue of being based on plugins) a platform for creating developer portals.
|
||||
|
||||
## Document (search plugin)
|
||||
|
||||
An abstract concept representing something that can be found by searching for it. A document can represent a software entity, a TechDocs page, etc. Documents are made up of metadata fields, at a minimum -- a title, text, and location (as in a URL).
|
||||
|
||||
## Domain
|
||||
|
||||
An area that relates systems or entities to a business unit. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## Entity
|
||||
|
||||
What is cataloged in the Backstage Software Catalog. An entity is identified by a unique combination of [kind](#Kind), [namespace](#Namespace), and name. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## Evaluator
|
||||
|
||||
Someone who assesses whether Backstage is a suitable solution for their organization. The only [user role](#user-role) with a pre-deployment [use case](#use-case).
|
||||
|
||||
## ID Token
|
||||
|
||||
A [JWT](#jwt) used to prove a user's identity, containing for example the user's email. Part of [OpenID Connect](#openid-connect).
|
||||
|
||||
## Index (search plugin)
|
||||
|
||||
An index is a collection of [documents](#documents) of a given type.
|
||||
|
||||
## Indexer (search plugin)
|
||||
|
||||
A write stream of [documents](#documents).
|
||||
|
||||
## Integrator
|
||||
|
||||
Someone who develops one or more plugins that enable Backstage to interoperate with another software system. A [user role](#user-role).
|
||||
|
||||
## JWT
|
||||
|
||||
JSON Web Token.
|
||||
|
||||
A popular JSON based token format that is commonly encrypted and/or signed, see [the Wikipedia article](https://en.wikipedia.org/wiki/JSON_Web_Token) for more details.
|
||||
|
||||
## Kind
|
||||
|
||||
Classification of an [entity](#Entity) in the Backstage Software Catalog, for example _service_, _database_, and _team_.
|
||||
|
||||
## Kubernetes (CNCF Project)
|
||||
|
||||
An open-source system for automating deployment, scaling, and management of containerized applications.
|
||||
|
||||
## Kubernetes (Backstage plugin)
|
||||
|
||||
A core Backstage plugin enabling a service owner-focused view of Kubernetes resources.
|
||||
|
||||
## Local Package
|
||||
|
||||
One of the [packages](#package) within a [monorepo](#monorepo). These package may or may not also be published to a [package registry](#package-registry).
|
||||
|
||||
## Monorepo
|
||||
|
||||
1. A single repository for a collection of related software projects, such as all projects belonging to an organization.
|
||||
|
||||
2. A project layout that consists of multiple [packages](#package) within a single project, where packages are able to have local dependencies on each other. Often enabled through tooling such as [lerna](https://lerna.js.org/) and [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/)
|
||||
|
||||
## Namespace (catalog plugin)
|
||||
|
||||
An optional attribute that can be used to organize [entities](#entity).
|
||||
|
||||
## Objective
|
||||
|
||||
A high level goal of a [user role](#User-Role) interacting with Backstage. Some goals of the _administrator_ user role, for example, are to maintain an instance ("app") of Backstage; to add and update functionality via plugins; and to troubleshoot issues.
|
||||
|
||||
## OAuth
|
||||
|
||||
Refers to: OAuth 2.0, a standard protocol for authorization. See [oauth.net/2/](https://oauth.net/2/).
|
||||
|
||||
## Offline Access
|
||||
|
||||
[OAuth](#oauth) flow that results in both a refresh token and [access token](#access-token), where the refresh token has a long expiration or never expires, and can be used to request more access tokens in the future. This lets the user go "offline" with respect to the token issuer, but still be able to request more tokens at a later time without further direct interaction for the user.
|
||||
|
||||
## OpenID Connect
|
||||
|
||||
A layer on top of [OAuth](#oauth) which standardises authentication. See [the Wikipedia article](https://en.wikipedia.org/wiki/OpenID_Connect) for more details.
|
||||
|
||||
## OSS
|
||||
|
||||
Open source software.
|
||||
|
||||
## Package
|
||||
|
||||
A package in the Node.js ecosystem, often published to a [package registry](#package-registry).
|
||||
|
||||
## Package Registry
|
||||
|
||||
A service that hosts [packages](#package). The most prominent example is [NPM](https://www.npmjs.com/).
|
||||
|
||||
## Package Role
|
||||
|
||||
The declared role of a package, see [package roles](../local-dev/cli-build-system.md#package-roles).
|
||||
|
||||
## Permission (core Backstage plugin)
|
||||
|
||||
A core Backstage plugin and framework that allows restriction of actions to specific users. See [their docs](https://backstage.io/docs/permissions/overview) for more information.
|
||||
|
||||
## Permission (permission plugin)
|
||||
|
||||
A restriction on any action that a user can perform against a specific [resource](#resource-permission-plugin) or set of resources. See [the permission framework docs](../permissions/concepts.md#permission) for more details.
|
||||
|
||||
## Persona (use cases)
|
||||
|
||||
Alternative term for a [User Role](#user-role).
|
||||
|
||||
## Plugin
|
||||
|
||||
A module in Backstage that adds a feature. All functionality outside of [the Backstage framework](#backstage-framework), even the core features, are implemented as plugins.
|
||||
|
||||
## Policy (permission plugin)
|
||||
|
||||
A construct that takes in a Backstage user and a [permission](#permission-permission-plugin) and returns a [policy decision](#policy-decision-permission-plugin).
|
||||
|
||||
## Policy Decision (permission plugin)
|
||||
|
||||
A specific response to a user's request to perform an action on a list of [resources](#resource-permission-plugin). Can be either `Approve`, `Deny` or [`Conditional`](#conditional-decision-permission-plugin).
|
||||
|
||||
## Popup
|
||||
|
||||
A separate browser window opened on top of the previous one.
|
||||
|
||||
## Procedure (use cases)
|
||||
|
||||
A set of actions that accomplish a goal, usually as part of a [use case](#Use-Case). A procedure can be high-level, containing other procedures, or can be as simple as a single [task](#Task).
|
||||
|
||||
## Query Translators (search plugin)
|
||||
|
||||
An abstraction layer between a search engine and the [Backstage Search](#search) backend. Allows for translation into queries against your search engine.
|
||||
|
||||
## Refresh token
|
||||
|
||||
A special token that an [OAuth](#oauth) client can use to get a new [access token](#access-token) when the latter expires.
|
||||
|
||||
https://oauth.net/2/refresh-tokens/
|
||||
|
||||
## Resource (catalog plugin)
|
||||
|
||||
An [entity](#entity) that represents a piece of physical or virtual infrastructure, for example a database, required by a component. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## Resource (permission plugin)
|
||||
|
||||
A representation of an object that a user interacts with and that can be permissioned. Not to be confused with [Software Catalog resources](#resource-catalog-plugin).
|
||||
|
||||
## Rule (permission plugin)
|
||||
|
||||
A predicate-based control that taps into a [resource](#resource-permission-plugin)'s data.
|
||||
|
||||
## Role
|
||||
|
||||
See [User Role](#User-Role).
|
||||
|
||||
## Scaffolder
|
||||
|
||||
Known as [Software Templates](#software-templates).
|
||||
|
||||
## Scope
|
||||
|
||||
A string that describes a certain type of access that can be granted to a user using OAuth, usually in conjunction with [access tokens](#access-token).
|
||||
|
||||
## Search
|
||||
|
||||
A Backstage plugin that provides a framework for searching a Backstage [app](#app), including the [Software Catalog](#Software-Catalog) and [TechDocs](#TechDocs). A core feature of Backstage.
|
||||
|
||||
## Search Engine (Backstage search)
|
||||
|
||||
Existing search technology that [Backstage Search](#search) can take advantage of through its modular design. Lunr is the default search in Backstage Search.
|
||||
|
||||
## Software Catalog
|
||||
|
||||
A Backstage plugin that provides a framework to keep track of ownership and metadata for any number and type of software [components](#component). A core feature of Backstage.
|
||||
|
||||
## Software Templates
|
||||
|
||||
A Backstage plugin with which to create [components](#component) in Backstage. A core feature of Backstage. Also known as the scaffolder.
|
||||
|
||||
## Software Template
|
||||
|
||||
A "skeleton" software project created and managed in the Backstage Software Templates tool.
|
||||
|
||||
## System (catalog plugin)
|
||||
|
||||
A system is a collection of [entities](#entity) that cooperate to perform a function. A system generally provides one or a few public APIs and consists of a handful of components, resources and private APIs. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
|
||||
## Task (use cases)
|
||||
|
||||
A low-level step-by-step [Procedure](#Procedure).
|
||||
|
||||
## TechDocs
|
||||
|
||||
A documentation solution that manages and generates a technical documentation from Markdown files stored with software component code. A core feature of Backstage.
|
||||
|
||||
## Token
|
||||
|
||||
A string containing information.
|
||||
|
||||
## Use Case
|
||||
|
||||
A purpose for which a [user role](#User-Role) interacts with Backstage. Related to [Objective](#objective): An objective is _what_ the user wants to do; a use case is _how_ the user does it.
|
||||
|
||||
## User Role
|
||||
|
||||
A class of Backstage user for purposes of analyzing [use cases](#use-case). One of: evaluator; administrator; developer; integrator; and contributor.
|
||||
@@ -0,0 +1,89 @@
|
||||
<!-- This document is meant to solely serve as reference for how to write glossary entries. -->
|
||||
|
||||
## Entry format
|
||||
|
||||
A glossary entry should consist of two required things and two optional things,
|
||||
|
||||
1. a header,
|
||||
2. a sentence defining what the thing is, and
|
||||
3. an optional additional sentence or two giving more context into what the thing is and possible pointers on where to find more information, and possibly
|
||||
4. links out to additional information.
|
||||
|
||||
### The header
|
||||
|
||||
The header (and first sentence) are the way users will discover your entry. The header has two parts,
|
||||
|
||||
1. The actual term, this should be as minimal as possible. You can fit more information into the body of the entry.
|
||||
2. A disambiguator, this allows users to understand when certain entries are context specific or may have different meanings in different contexts.
|
||||
|
||||
### The term
|
||||
|
||||
Think of this as a dictionary. Single words are the base units and most definitions refer to a single word. Acronyms are acceptable. An adjective and a noun are also useful, `conditional decision`, `backstage framework`, etc. After 3 or _maybe_ 4 words, you should be trying to simplify and place more content in your entry instead.
|
||||
|
||||
In the title, your term should be in Title Case. It should also be in the singular.
|
||||
|
||||
### The disambiguator
|
||||
|
||||
The goal of a disambiguator is to differentiate terms that may have context specific meanings. This can have two interpretations, either
|
||||
|
||||
1. There are multiple terms and we need to create clear boundaries between their contexts, or
|
||||
2. There are single terms that have meanings that are specific to a single context.
|
||||
|
||||
A good example for the first would be resources. Both the catalog plugin and permission plugin have the idea of resources, but they do not refer to the same thing.
|
||||
|
||||
A good example for the second would be `Query translators`. In our case, this refers to _search_ query translators, but it may refer to database query translators or the latter. By disambiguating early, we avoid confusion.
|
||||
|
||||
Beyond the above advice, there are no strong rules for when or when not to use a disambiguator. It is up to the entry writer and the reviewer.
|
||||
|
||||
Your disambiguator should be short, but need not be a single word -- examples include "use cases", "search plugin", "catalog plugin". When used the disambiguator should have the following form, `({disambiguator})` (a parenthesis enclosed term) and will sit to the right of the title. Your disambiguator should use lower case.
|
||||
|
||||
### Putting it together
|
||||
|
||||
Your title should look like `{word} ({disambiguator})`. Entries are not nested besides the disambiguator and should sit at `##`.
|
||||
|
||||
## The first sentence
|
||||
|
||||
Your first sentence should include the what for your word. Your goal should be to answer the question, "What is x?". Do _not_ use the word in your first sentence. If you are using other words in the glossary in your definition, you should reference them following [the Referencing section](#referencing).
|
||||
|
||||
If you have a term that could mean multiple things in the same context or the context is difficult to add boundaries for, you should separate each meaning into a separate section of the entry using an ordered list. For example,
|
||||
|
||||
```md
|
||||
## Bundle
|
||||
|
||||
1. A deployment artifact.
|
||||
2. A collection of packages.
|
||||
```
|
||||
|
||||
## Additional sentences
|
||||
|
||||
You may not be able to fully define what you want in a single sentence. Use more sentences to flush out the meaning; however, if you start to get into the weeds, you should reconsider rehousing that information into a plugin specific "concepts" section. It's okay for words to be duplicated across both if the concepts section adds meaningful technical or architectural discussion.
|
||||
|
||||
## Linking out to additional resources
|
||||
|
||||
If the term you're defining has a better or more in depth source for that information, link to it. This can include plugin specific concept documents, external documentation, or core framework documentation.
|
||||
|
||||
You should format these links as
|
||||
|
||||
```md
|
||||
See [the glossary](./glossary.md) for more details.
|
||||
```
|
||||
|
||||
. Additional links beyond the first one should be appended with `and` or `or` as necessary.
|
||||
|
||||
## Putting it all together
|
||||
|
||||
```md
|
||||
## Component (catalog plugin)
|
||||
|
||||
A software product that is managed in the Backstage [Software Catalog](#software-catalog). A component can be a service, website, library, data pipeline, or any other piece of software managed as a single project. See [the catalog docs](https://backstage.io/docs/features/software-catalog/system-model) for more information.
|
||||
```
|
||||
|
||||
## Referencing
|
||||
|
||||
### In the glossary
|
||||
|
||||
You should reference often. Words are defined recursively, especially in tech and un-nesting some terms requires additional glossary items. It's okay if your terms require multiple other terms to build on. Your goal with referencing is to provide small reusable words that you can trust users know the definition of.
|
||||
|
||||
### In the text
|
||||
|
||||
You should reference (and create a new entry if it doesn't exist) whenever you see a new word that a reasonable reader may not know. If you've already added a reference in your current passage -- in the glossary this will be your entry -- don't add a new reference. References should point initially to the glossary and if there is additional information (like a concepts page), the glossary should have a link to that page.
|
||||
Reference in New Issue
Block a user