Certified Backstage Associate flashcards
Certified Backstage Associate · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- create-app CLI
- The `npx @backstage/create-app@latest` command scaffolds a new Backstage instance, generating the frontend, backend, and plugin package structure with default configuration.
- yarn dev command
- Starts the Backstage frontend (port 3000) and backend (port 7007) locally with hot reload, used during development to preview changes.
- backstage.json version file
- A root-level file recording the Backstage release version; `yarn backstage-cli versions:bump` updates dependencies to a newer release.
- yarn new scaffolder
- The `yarn new` command generates boilerplate for new plugins or packages, prompting for plugin type such as frontend-plugin or backend-plugin.
- app-config.yaml base config
- The primary configuration file at the repo root; environment-specific overrides live in app-config.local.yaml (git-ignored) or app-config.production.yaml.
- backend plugin registration
- Backend plugins are registered in packages/backend/src/index.ts by calling their factory and mounting the router with apiRouter.use or the backend system's addRouter.
- yarn tsc type-check
- Runs TypeScript type-checking across the workspace; `yarn tsc:full` includes all packages, while `yarn lint` and `yarn test` handle linting and Jest tests.
- createPlugin frontend factory
- A function from @backstage/core-plugin-api that defines a frontend plugin with an id, routes, and apis, exported for use in the app.
- backend port 7007
- The default port for the Backstage backend Node.js service; the frontend calls it via the backend.baseUrl configuration value.
- backend.database config
- Configures the catalog database client: better-sqlite3 for development, pg for PostgreSQL, or mysql2 for MySQL, with connection details supplied via environment variables.
- auth.providers config
- Defines authentication providers (GitHub, Google, Okta, etc.) with client ID/secret and a redirect URL pointing to <frontend-url>/api/auth/<provider>/handler/frame.
- backend.listen config
- Controls the host and port the backend binds to; set backend.listen.port and backend.listen.host explicitly in containerized deployments.
- environment variable interpolation
- app-config.yaml supports ${ENV_VAR} syntax to inject secrets and environment-specific values, keeping credentials out of committed files.
- TechDocs builder modes
- techdocs.builder can be 'local' (build during dev) or 'external' (build in CI); external builds require a publisher like awsS3, googleGcs, or azureBlobStorage.
- healthcheck endpoint
- The backend exposes /healthcheck for Kubernetes liveness and readiness probes, returning a status indicating service health.
- frontend static hosting
- The frontend is built with yarn build into static assets served by any static host (Nginx, S3+CloudFront); it calls the backend via backend.baseUrl.
- entity manifest apiVersion
- Catalog entities use apiVersion backstage.io/v1alpha1 (or v1beta1 for newer kinds) plus a kind such as Component, API, System, Domain, Group, User, or Resource.
- metadata.name and namespace
- Every entity requires metadata.name, unique within its kind and namespace; metadata.namespace defaults to 'default', and metadata.uid is assigned by the catalog.
- spec.type and lifecycle
- spec.type classifies a Component (service, website, library); spec.lifecycle records its stage (production, experimental, deprecated).
- ownership relations
- spec.owner references a Group or User; spec.system links a Component to a System, and spec.domain links a System to a Domain, forming the relationship graph.
- catalog.locations config
- Defines entity ingestion sources in app-config.yaml, each with a type (url, file, github, gitlab, bitbucket) and a target the processor reads.
- catalog.rules allow list
- The catalog.rules array controls which entities are accepted; each rule matches on kind (and optionally spec.type) and sets allow: [Component, System, ...].
- catalog processors pipeline
- Entity processing runs through processors defined under catalog.processors, such as builtin-entity-relations, which derive relations from entity fields.
- catalog entities API
- GET /api/catalog/entities lists entities; GET /api/catalog/entities/by-name/<kind>/<namespace>/<name> fetches one entity; the frontend uses catalogApiRef.
- dependsOn and providesApis
- spec.dependsOn lists entities a component depends on; spec.providesApis and spec.consumesApis link components to API entities, generating relations in the graph.
- createTheme customization
- The @backstage/theme createTheme function builds a theme object passed to createApp({ theme: [...] }), optionally with light and dark variants.
- createApp components override
- createApp accepts a components object to override SignInPage, Router, Sidebar, and other layout components for app-wide customization.
- EntityLayout.Route tabs
- Entity pages are extended by adding EntityLayout.Route entries in EntityPage.tsx, each rendering a custom component as a new tab.
- EntitySwitch guards
- EntitySwitch with isKind and isComponentType guards renders different layouts per entity kind or type on the catalog entity page.
- createApiRef custom API
- Defines a custom API client reference provided to the app via createApp apis or ApiProvider; components consume it with useApi.
- createTemplateAction scaffolder
- Registers a custom Scaffolder action by creating it with createTemplateAction and adding it to the scaffolder backend plugin's actions list.
- app.title branding
- The app section of app-config.yaml controls branding: app.title sets the browser title and app.baseUrl sets the frontend base path.