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

Fix image link in ADR 5 (#1125)

Browse Source
This commit is contained in:
Stefan Ålund
2020-06-03 13:19:07 +02:00
committed by GitHub
parent a6ce6b28e0
commit 5b9f77f151
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture-decisions/adr005-catalog-core-entities.md
+3 -3
View File
@@ -16,7 +16,7 @@ Backstage should eventually support the following core entities:
* **APIs** are the boundaries between different components
* **Resources** are physical or virtual infrastructure needed to operate a component
![Catalog Core Entities][catalog-core-entities]
![Catalog Core Entities](catalog-core-entities.png)
For now, we'll start by only implementing support for the Component entity in the Backstage catalog. This can later be extended to APIs, Resources and other potentially useful entities.
@@ -36,7 +36,7 @@ spec:
### API
APIs form an abstraction that allows large software ecosystems to scale. Thus, APIs are a first class citizen in the Backstage model and the primary way to discover existing functionality in the ecosystem.
APIs are implemented by components and make their boundaries explicit. They might be defined using an RPC IDL (eg in Protobuf, GraphQL or similar), a data schema (eg in Avro, TFRecord or similar), or as code interfaces (eg framework APIs in Swift, Kotlin, Java, C++, Typescript etc). In any case, APIs exposed by components need to be in a known machine-readable format so we can build further tooling and analysis on top.
APIs are implemented by components and make their boundaries explicit. They might be defined using an RPC IDL (e.g. in Protobuf, GraphQL or similar), a data schema (e.g. in Avro, TFRecord or similar), or as code interfaces (e.g. framework APIs in Swift, Kotlin, Java, C++, Typescript etc). In any case, APIs exposed by components need to be in a known machine-readable format so we can build further tooling and analysis on top.
APIs are typically indexed from existing definitions in source control and thus wouldn't need their own descriptor files, but would be stored in the catalog somewhat like this (actual schema will evolve):
```yaml
@@ -61,7 +61,7 @@ spec:
### Resource
Resources are the infrastructure your software needs to operate at runtime like Bigtable databases, Pub/Sub topics, S3 buckets or CDNs. Modelling them together with components and APIs will allow us to visualize and create tooling around them in Backstage.
Resources are typically indexed from declarative definitions (eg Terraform, GCP Config Connector, AWS Cloud Formation) and/or inventories from cloud providers (eg GCP Asset Inventory) and thus wouldn't need their own descriptor files, but would be stored in the catalog somewhat like this (actual schema will evolve):
Resources are typically indexed from declarative definitions (e.g. Terraform, GCP Config Connector, AWS Cloud Formation) and/or inventories from cloud providers (e.g. GCP Asset Inventory) and thus wouldn't need their own descriptor files, but would be stored in the catalog somewhat like this (actual schema will evolve):
```yaml
apiVersion: backstage.io/v1beta1
kind: Resource