API Catalog

APIs are closely related to microservices, as obviously, the connections between independent teams get crucial. Companies thrive for consistency among APIs to foster internal and external developer experience, for reuse where appropriate, and consolidation, especially in a rapidly growing landscape.

API Management tools

There is a variety of modern tools that help development departments to structure and unify the variety of managed APIs, examples are Kong, Apigee, Axway and MuleSoft. Standardized formats like OpenAPI or Swagger provide the baseline for auto-generated API documentation.

How LeanIX can help

Depending on your current toolchain, LeanIX can support two scenarios:

  1. API Management solution in place

An API Management tool is great to capture technical dependencies, but often struggles to:

  • Embrace the domain or business context
  • Create a clear linkage to responsibilities
  • Provide easy entry points for non-experts
  • Provide dynamic, graphical capabilities to explore impacts & dependencies

Those four points are addressed by VSM and can justify a co-existence of both toolings. As API Management solutions naturally provide open APIs as well, a connection is fairly simple as described below.

  1. No API Management solution in place

In this case, adding to the points above VSM can support setting up an API catalog without a management tool. Approaches can be:

  • Manual documentation (obviously only recommended as a stop-gap solution)
  • Discovery of APIs based on CI/CD, e.g. by extracting Swagger definition files

📘

Information

An additional potential source for APIs are service meshes like https://istio.io/ - please get in touch with [email protected] to discuss options

How to discover APIs

The LeanIX Integration API provides a highly flexible way to map API data into the Data Model. The following processor and sample LDIF provides a baseline that could be easily extended, e.g. to write:

{
    "processors": [
        {
            "processorType": "inboundFactSheet",
            "processorName": "API FS creation",
            "type": "API",
            "filter": {
                "exactType": "API"
            },
            "identifier": {
                "external": {
                    "id": {
                        "expr": "${content.id}"
                    },
                    "type": {
                        "expr": "externalId"
                    }
                }
            },
            "run": 0,
            "updates": [
                {
                    "key": {
                        "expr": "name"
                    },
                    "values": [
                        {
                            "expr": "${data.app}"
                        }
                    ]
                }
            ]
        },
        {
            "processorType": "inboundRelation",
            "processorName": "Relation from API to Consumer Microservice",
            "type": "relAPIToConsumerMicroservice",
            "filter": {
                "exactType": "API"
            },
            "from": {
                "external": {
                    "id": {
                        "expr": "${content.id}"
                    },
                    "type": {
                        "expr": "externalId"
                    }
                }
            },
            "to": {
                "external": {
                    "id": {
                        "expr": "${integration.valueOfForEach}"
                    },
                    "type": {
                        "expr": "externalId"
                    }
                }
            },
            "run": 1,
            "forEach": "${data.consumers}"
        },
        {
            "processorType": "inboundRelation",
            "processorName": "Rel from API to Provider Microservice",
            "type": "relAPIToProviderMicroservice",
            "filter": {
                "exactType": "Interface"
            },
            "from": {
                "external": {
                    "id": {
                        "expr": "${content.id}"
                    },
                    "type": {
                        "expr": "externalId"
                    }
                }
            },
            "to": {
                "external": {
                    "id": {
                        "expr": "${data.provider}"
                    },
                    "type": {
                        "expr": "externalId"
                    }
                }
            },
            "run": 1
        }
    ]
}
"content": [
  {
    "type": "API",
    "id": "API-123",
    "data": {
      "name": "Test API",
      "provider": "MS-123",
      "consumers": ["MS-456", "MS-789"]
    }
  }
]

End-to-End example: Leverage Jaeger to detect APIs and call frequency

Jaeger is a popular Open-Source distributed tracing project. It helps to monitor and troubleshoot transactions in complex distributed systems, while it can create architecture graphs as fallout as well.

The Jaeger HotROD example can be used to demonstrate getting API data into VSM within minutes. To get started, run the Jaeger Backend and the HotROD client as in the tutorial. Then, use jaeger.py to extract an LDIF from your local Jaeger environment.

🚧

Attention

In productive settings, using the gRPC/Protobuf API is recommended.

The extracted LDIF can then be uploaded to your VSM workspace using the Integration API and a processor set like provided here. It will immediately give you:

a) A list of connected Microservice and API Fact Sheets

b) The opportunity to use the Data Flow or Relation Explorer to navigate and export dependencies

c) The option to use tracing data on heatmaps, e.g. grouped by providing Microservice

d) Tracing data over time in the Metrics module


Did this page help you?