Skip to content
Structly Docs
한국어

Concepts

Catalog types and connections

On this page

Catalog types#

CatalogWeb UI menustly resourceWhat it records
SystemSystemssystemsA composition that groups Services, APIs, and Systems
ServiceServicesservicesName, summary, description, and manual Status
APIAPIsapisName, summary, description, and base URLs for calls
EndpointEndpointsendpointsHTTP Method and Path, and the Schema and examples of Parameters, Headers, the Request Body, and Responses
WorkflowWorkflowsworkflowsOrdered Steps that call Endpoints and Workflows
DatabaseDatastoresdatabasesDatabase Metadata and its engine-specific structures
MessagingQueuesmessaging-clusters·kafka-topicsKafka Clusters and Topics, Message Definitions, and publish and consume usage notes
RepositoryRepositoriesrepositoriesName, Git URL, description, and OpenAPI, AsyncAPI, and Arazzo spec documents

The structures that belong to a Database depend on its engine.

engineStructurestly resource
PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL ServerTabletables
MongoDBCollectioncollections
RedisKey Patternkey-patterns
CassandraTablecassandra-tables

Address names#

Systems, Services, APIs, Workflows, Databases, Messaging Clusters, and Repositories have a handle in addition to their name. The handle identifies the entry in the Web address and is unique within the same Catalog of the same Organization.

https://<Structly address>/o/acme/services/orders-service
  • It has 3 to 39 lowercase letters, digits, and hyphens and can start with a digit. It cannot start or end with a hyphen or contain consecutive hyphens.
  • It is required when you create an entry. The Web UI fills in a candidate made from the name; enter it yourself when the name has only Korean characters.
  • Renaming an entry does not change its handle. If you change the handle, the previous address is released immediately and another entry can use it. The old address does not redirect to the new one.
  • A Database cannot use structures.
  • Endpoints and structures such as Tables and Topics use their ID in the address instead of a handle.
  • Connections and stly commands still use the ID to identify a target.

Connections between Catalogs#

ConnectionDescription
API → ServiceEach API names one providing Service. The Service detail shows the APIs it provides.
API → EndpointAn Endpoint optionally belongs to one API.
Service → RepositoryConnects the Repositories that hold a Service's code.
Service → Database, structuresConnects the Databases and the Key Patterns, Tables, Collections, and Cassandra Tables a Service uses.
Service → Kafka TopicA Topic's publish and consume usage notes can name a Service.
System → Service, API, SystemRecords what a System directly contains. A System can contain other Systems, but cycles are not allowed.
Workflow → Endpoint, WorkflowEach Workflow Step names the Endpoint or other Workflow it calls.
OpenAPI document → API, EndpointEach OpenAPI document links to one API, and approved changes are applied to the API and its Endpoints. Documents live in a Repository or are registered without one.

You can navigate connected entries from both sides. For example, a Service detail shows the APIs it provides, and an API detail shows its providing Service. Some Catalogs cannot be deleted while connections to other entries remain. For the conditions, see each page in the Catalog guides.

The search box at the top of the Web UI (⌘K or Ctrl+K) and stly catalog search search the names, summaries, and descriptions of multiple Catalogs at once. They also match Endpoint Paths and Workflow Keys, and are not case-sensitive.

stly catalog search --q orders