Merge remote-tracking branch 'upstream/master'
This commit is contained in:
Clare Liguori
+1
-1
@@ -54,7 +54,7 @@ begun work on various aspects of all three phases. Looking at the
|
||||
[milestones for active issues](https://github.com/backstage/backstage/milestones)
|
||||
will also give you a sense of our progress.
|
||||
|
||||
### My company doesn't have thousands of developers or services. Is Backstage overkill?
|
||||
### My company doesn't have thousands of developers or services. Is using Backstage excessive for our needs?
|
||||
|
||||
Not at all! A core reason to adopt Backstage is to standardize how software is
|
||||
built at your company. It's easier to decide on those standards as a small
|
||||
|
||||
@@ -10,7 +10,7 @@ description: Architecture Decision Record (ADR) for Luxon Date Library
|
||||
Date formatting (e.g. `a day ago`) and calculations are common within Backstage.
|
||||
Some of these useful features are not supported by the standard JavaScript
|
||||
`Date` object. The popular [Moment.js](https://momentjs.com/) library has been
|
||||
commonly used to fill this gap but suffers from large bundle sizes and mutable
|
||||
commonly used to fill this gap but is affected by large bundle sizes and mutable
|
||||
state issues. On top of this, `momentjs` is
|
||||
[being sunset](https://momentjs.com/docs/#/-project-status/) and the project
|
||||
recommends using one of the more modern alternative libraries.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 80 KiB |
@@ -63,7 +63,7 @@ export default async function createPlugin(
|
||||
// and the access token and produces the Backstage token with the
|
||||
// relevant user info.
|
||||
async resolver({ profile, result }, ctx) {
|
||||
// Somehow compute the Backstage token claims. Just some dummy code
|
||||
// Somehow compute the Backstage token claims. Just some sample code
|
||||
// shown here, but you may want to query your LDAP server, or
|
||||
// https://<teamName>.cloudflareaccess.com/cdn-cgi/access/get-identity
|
||||
// https://developers.cloudflare.com/cloudflare-one/identity/users/validating-json/#groups-within-a-jwt
|
||||
|
||||
@@ -70,7 +70,7 @@ export default async function createPlugin(
|
||||
// and the IAP token and produces the Backstage token with the
|
||||
// relevant user info.
|
||||
async resolver({ profile, result: { iapToken } }, ctx) {
|
||||
// Somehow compute the Backstage token claims. Just some dummy code
|
||||
// Somehow compute the Backstage token claims. Just some sample code
|
||||
// shown here, but you may want to query your LDAP server, or
|
||||
// GSuite or similar, based on the IAP token sub/email claims
|
||||
const id = iapToken.email.split('@')[0];
|
||||
|
||||
@@ -256,7 +256,7 @@ bash-5.1# exit
|
||||
|
||||
The database pod is running, but how does another pod connect to it?
|
||||
|
||||
Kubernetes pods are transient - they can be killed, restarted, or created
|
||||
Kubernetes pods are transient - they can be stopped, restarted, or created
|
||||
dynamically. Therefore we don't want to try to connect to pods directly, but
|
||||
rather create a Kubernetes Service. Services keep track of pods and direct
|
||||
traffic to the right place.
|
||||
|
||||
@@ -360,7 +360,7 @@ Fields of a link are:
|
||||
_NOTE_: The `icon` field value is meant to be a semantic key that will map to a
|
||||
specific icon that may be provided by an icon library (e.g. `material-ui`
|
||||
icons). These keys should be a sequence of `[a-z0-9A-Z]`, possibly separated by
|
||||
one of `[-_.]`. Backstage may support some basic icons out of the box, but the
|
||||
one of `[-_.]`. Backstage may support some basic icons out of the box such as those [defined in app-defaults](https://github.com/backstage/backstage/blob/master/packages/app-defaults/src/defaults/icons.tsx), but the
|
||||
Backstage integrator will ultimately be left to provide the appropriate icon
|
||||
component mappings. A generic fallback icon would be provided if a mapping
|
||||
cannot be resolved.
|
||||
|
||||
@@ -50,7 +50,7 @@ components need to be in a known machine-readable format so we can build further
|
||||
tooling and analysis on top.
|
||||
|
||||
APIs have a visibility: they are either public (making them available for any
|
||||
other component to consume), restricted (only available to a whitelisted set of
|
||||
other component to consume), restricted (only available to an allowlisted set of
|
||||
consumers), or private (only available within their system). As public APIs are
|
||||
going to be the primary way interaction between components, Backstage supports
|
||||
documenting, indexing and searching all APIs so we can browse them as
|
||||
|
||||
@@ -260,7 +260,7 @@ development dependency only.
|
||||
|
||||
It can sometimes be difficult to decide where to place your plugin code. For example
|
||||
should it go directly in the `-backend` plugin package or in the `-node` package?
|
||||
As a rule of thumb you should try to keep the exposure of your code as low
|
||||
As a general guideline you should try to keep the exposure of your code as low
|
||||
as possible. If it doesn't need to be public API, it's best to avoid. If you don't
|
||||
need it to be used by other plugins, then keep it directly in the plugin packages.
|
||||
|
||||
|
||||
@@ -52,13 +52,13 @@ learn how to contribute the integration yourself!
|
||||
The following table summarizes events that, depending on the plugins you have
|
||||
installed, may be captured.
|
||||
|
||||
| Action | Subject | Other Notes |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- |
|
||||
| `navigate` | The URL of the page that was navigated to | |
|
||||
| `click` | The text of the link that was clicked on | The `to` attribute represents the URL clicked to |
|
||||
| `create` | The `name` of the software being created; if no `name` property is requested by the given Software Template, then the string `new {templateName}` is used instead. | The context holds an `entityRef`, set to the template's ref (e.g. `template:default/template-name`) |
|
||||
| `search` | The search term entered in any search bar component | The context holds `searchTypes`, representing `types` constraining the search |
|
||||
| `discover` | The title of the search result that was clicked on | The `value` is the result rank. A `to` attribute is also provided |
|
||||
| Action | Subject | Other Notes |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `navigate` | The URL of the page that was navigated to | |
|
||||
| `click` | The text of the link that was clicked on | The `to` attribute represents the URL clicked to |
|
||||
| `create` | The `name` of the software being created; if no `name` property is requested by the given Software Template, then the string `new {templateName}` is used instead. | The context holds an `entityRef`, set to the template's ref (e.g. `template:default/template-name`) |
|
||||
| `search` | The search term entered in any search bar component | - The context holds `searchTypes`, representing `types` constraining the search. The `value` represents the total number of search results for the query. This may not be visible if the permission framework is being used. |
|
||||
| `discover` | The title of the search result that was clicked on | The `value` is the result rank. A `to` attribute is also provided |
|
||||
|
||||
If there is an event you'd like to see captured, please [open an
|
||||
issue][add-event] describing the event you want to see and the questions it
|
||||
|
||||
@@ -51,7 +51,7 @@ terminal window, now run
|
||||
curl localhost:7007/carmen/health
|
||||
```
|
||||
|
||||
This should return `{"status":"ok"}`. Success! Press `Ctrl + c` to kill it
|
||||
This should return `{"status":"ok"}`. Success! Press `Ctrl + c` to stop it
|
||||
again.
|
||||
|
||||
## Developing your Backend Plugin
|
||||
|
||||
@@ -123,7 +123,7 @@ than simply letting them know they had an invalid input.
|
||||
> input change.
|
||||
|
||||
This piggybacks the Scalability Principle and applies primarily to frontend
|
||||
development. As a general rule of thumb, frontends should be flexible enough so
|
||||
development. As a general guideline, frontends should be flexible enough so
|
||||
that the UX or design can change while touching the least amount of code
|
||||
possible. So for example, a poor unit test would verify the color of a button
|
||||
when it is hovered. This would be a poor unit test, because if you decide to
|
||||
@@ -353,7 +353,7 @@ For more information:
|
||||
### Accessing `store`, `theme`, routing, browser history, etc.
|
||||
|
||||
The Backstage application has several core providers at its root. To run your
|
||||
test wrapped in a "dummy" Backstage application, you can use our utility
|
||||
test wrapped in a "sample" Backstage application, you can use our utility
|
||||
functions:
|
||||
|
||||
**`wrapInTestApp`**
|
||||
|
||||
@@ -268,7 +268,7 @@ async function main() {
|
||||
```
|
||||
|
||||
This will be run every time you restart the backend. Note that after any change
|
||||
in the URL Reader code, you need to kill the backend and restart, since the
|
||||
in the URL Reader code, you need to stop the backend and restart, since the
|
||||
`reader` instance is memoized and does not update on hot module reloading. Also,
|
||||
there are a lot of unit tests written for the URL Readers, which you can make
|
||||
use of.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -21,8 +21,8 @@ instance or cluster.
|
||||
With infrastructure defined as code or data (Terraform, AWS CloudFormation,
|
||||
etc.), you may have database credentials which lack permissions to create new
|
||||
databases or you do not have control over the database names. In these
|
||||
instances, you can set the database name and connection information on a per
|
||||
plugin basis as mentioned earlier.
|
||||
instances, you can set the database connection configuration on a [per plugin basis]
|
||||
(#connection-configuration-per-plugin).
|
||||
|
||||
Backstage supports all of these use cases with the `DatabaseManager` provided by
|
||||
`@backstage/backend-common`. We will now cover how to use and configure
|
||||
|
||||
Reference in New Issue
Block a user