Manage your APIs using an internal developer portal

January 22, 2024

Manage your APIs using an internal developer portal

Ready to start?

Manage your APIs using an Internal Developer Portal

An API Catalog should be housed in an Internal Developer Portal as it is built to abstract away complexity for dev teams 

The best description for an API catalog is quite simply a highly organized library of APIs. Just like picking out a book in an actual library, the catalog makes APIs easily discoverable so that the developers and engineering leaders who need to use them can do so with ease. 

But while it may be organized and make life easier for those using APIs, other parts of software architecture also require organizing, and it makes sense to ensure all of the parts are in the same library. That way, you can find the API you’re looking for, but also get more contextual information about the APIs. 

This is why it makes sense to use an Internal Developer Portal for your private API Catalog. The Internal Developer Portal already links various parts of software architecture together, including microservices, dependencies, and resources. The portal acts as a user-friendly interface for the developer platform, built for the questions and needs of different dev teams and with the primary objective to improve developer experience. 

A portal that incorporates APIs can help developers answer questions about any API such as: 

  • What is the average response time of this API?
  • What was the last response time for this API?
  • Who is this API being used by?
  • How stable is this API?
  • How can I use this API?

API Catalogs, Defined 

The private API catalog is service-focused, helping developers to find the APIs they need from all internal APIs that are used within the organization. 

They help by:

  •  Optimizing API management by identifying redundant code and promoting adherence to organizational standards. 
  •  Avoiding the need to repetitively code common workflows such as user authentication. Instead, they can leverage APIs developed by other teams for similar purposes.
  •  Providing real-time insights into internal API usage trends, enabling informed decisions regarding resource allocation. 
  • Simplifying the enforcement of an effective API governance strategy across all organizational teams and preventing unnecessary microservices or orphaned APIs. 

An API Catalog Belongs In The Software Catalog

A core pillar of the Internal Developer is a software catalog; a centralized metadata repository for software and its underlying resources - microservices, cloud resources, Kubernetes clusters, and more. The software catalog provides customizable contextual information about any resource or service such as what the service does, where it is deployed, who the owner of the service is, and the stability of the service. 

It would make sense for the API catalog to be part of the overall software catalog as APIs are service-focused and tied to many other parts of the software architecture. With the portal, developers would be able to overcome any struggles they have in calling, tracking and deploying APIs as they would gain more visibility.  

For instance, microservices architectures often have a host of APIs that communicate with each other across a variety of interfaces and methods, which developers may want to track. By doing so, they can obtain a high-quality layer of observability and context - enabling the tracking of API versions, usage and dependencies helps them check that APIs are functioning properly or quickly identify any potential issues. The portal would enable them to do this, and reduce the time spent on discovering, monitoring and reusing APIs. Storing the API information within the portal enables developers to understand connections with other services housed in the developer portal. Attempting to access this information separately is tedious and adds to the developers workload (Checking the software catalog for related APIs or routes is much faster than checking the code directly, especially for someone who hasn’t used the API before). 

In addition, debugging and troubleshooting requires a deep understanding of APIs and the intricacies of the microservices, which not all developers have time to dive into. The same goes for integrating with third-party or new systems, which calls for deep knowledge of each system. There are also security demands, which require collaboration with security teams and a working knowledge of security requirements. And the list goes on.

One of the main advantages of having an API catalog within an Internal Developer Portal is that it can answer these challenges and more by abstracting away complexities and showing developers only the information they need for the API actions they need to take at a given time. This helps streamline and manage the process with efficiency and scale, which reduces cognitive load and frees developers to focus on their core activities, like writing high-performing and scalable code for the APIs.

Portals contain more than just software catalogs. They provide self-service actions that simplify the process of calling and consuming APIs, eliminate duplicate coding, and provide visibility and context. 

What Can You Do With An API Catalog in an Internal Developer Portal

Some practical uses of a API data within a software catalog include:

  • Troubleshooting and maintenance: When issues arise, developers can quickly refer to the software catalog to isolate the problem and understand its impact on interconnected systems. For example, by looking at the latest health check response time or status, you can see whether the API endpoints are degraded, unhealthy or unavailable. Additionally, you can use this information to quickly identify the root cause of the issue and take corrective action.

The software catalog also provides developers with additional context into the APIs provided and consumed by services. This information is valuable as a proactive measure to prevent incidents.

  • On-call response: If a developer needs to tend to an API-related incident, the portal provides guidance in an automated and self-service manner. The portal enables the developer to understand the state of various APIs and their routes make it easy to figure out what went wrong and what requires taking a look at. Being able to trigger a health check using a self-service action directly from the portal makes it easy to validate if the issue is still ongoing and provides more insight into the area that needs to be looked at. This streamlined process makes it very easy for the on-call developer to take care of an incident, even if it's 4 AM, they just woke up and it’s a mission-critical API.
  • Onboarding and training: New team members can use the software catalog as a learning tool to understand the organization's API infrastructure, speeding up the onboarding process. If a developer needs to add a new feature or develop a new API, they might be wondering whether there is already a similar functionality inside the organization. If so, they can use the endpoint that already exists rather than developing it.
  • Ongoing development: An API catalog provides developers with information about existing APIs, preventing them from redeveloping an endpoint that already exists.
  • Strategic planning: By building the API catalog inside the portal’s software catalog, decision makers can get a clear overview of the API landscape, which helps with strategic planning and resource allocation.
  • Long-term improvement of APIs:  With the API catalog in place, it is possible to use scorecards to keep track of organizational standards and best practices, and make sure the various APIs in the organization adhere to them. Things such as ‘expected average latency’, ‘number of 5xx status codes in the past day’ and other similar examples can be transformed into scorecards, while initiatives can be started for APIs that are not up to standard just yet.

API Management, Simplified

An Internal Developer Portal is a great solution for managing API complexities in a microservices architecture. It serves as a strategic asset, significantly improving the efficiency, security and scalability of your organization's API infrastructure. By providing a centralized, user-friendly and self-service interface, the portal simplifies API processes like troubleshooting, maintenance, onboarding and strategic planning.

The API catalog in Port's Internal Developer Portal offers comprehensive and real-time insights into the health and performance of APIs. Developers benefit from reduced cognitive load and automated workflows, allowing them to focus on core development tasks and innovate without having to spend time figuring out the intricacies of API management.

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start