Q: Senior engineers prefer working in their terminal using a CLI, while product managers and QA engineers prefer web portals like Backstage or Port. How do you design an internal platform API that serves both interfaces without duplicating business logic and governance rules?
Architectural design of a unified, headless platform API powering both terminal CLIs and web developer portals with consistent RBAC and validation.
Want to master this scenario in a live sandbox? KodeKloud's CKA & CKAD Hands-On Certification Track covers this exact problem with hands-on terminal drills.
🛠️ Production Runbook & Step-by-Step Resolution
Design OpenAPI/gRPC Platform Service Contract
Define declarative API specs for platform capabilities: `POST /v1/environments`, `POST /v1/services`, `GET /v1/templates`. All parameter validations, quota checks, and authorization rules reside on this central service.
# openapi.yaml snippet
paths:
/v1/environments:
post:
summary: Provision ephemeral environment
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/EnvironmentRequest'Build Lightweight Developer CLI (`acmectl`) Consuming the Platform API
Write `acmectl` in Go using Cobra. It handles local developer identity via SSO (`acmectl login`) and issues authorized requests to the central Platform API.
# Developer runs in terminal:
acmectl env create --name pr-42 --ttl 4h
acmectl catalog view checkout-apiBackstage UI Plugs Into the Same Platform Backend
The Backstage frontend custom plugin acts simply as a web client to the Platform API, ensuring that whether a resource is vended via UI or CLI, the exact same policies and audit logs trigger.
- Design platform operations as a centralized REST/gRPC API before building user interfaces.
- Build a lightweight Go CLI (acmectl) for terminal-centric developers that queries the platform API.
- Use Backstage as a visual client consuming the exact same backend endpoints and authorization rules.