aim-gateway-domain

Govern gateway-only exposure of public REST and WebSocket endpoints.

4|Updated May 17, 2026
One-click install
npx skills add https://github.com/hellopoisonx/aim --skill aim-gateway-domain
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: aim-gateway-domain
Source: https://github.com/hellopoisonx/aim/tree/main/skills/aim-gateway-domain
Command: npx skills add https://github.com/hellopoisonx/aim --skill aim-gateway-domain

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents accidental leakage of public REST/WebSocket endpoints from non-gateway services and keeps AIM client-facing contracts consistent across gateway and related protocols.

Core Features & Use Cases

  • External interface boundary governance: Enforces that only the gateway domain exposes public REST APIs and the WebSocket entry, while other domains must use internal gRPC/Kafka and must not publish REST/WS ports in Docker.
  • Gateway contract documentation: Centralizes REST proxy boundaries, WebSocket frame responsibilities, and gRPC push semantics (message, presence, typing, notifications, kick, drain).
  • Change tracking for client-facing schemas: Maintains a recent-changes log that highlights updates like friend tags, unified search, read receipts, typing/presence pipelines, and schema field alignment.

Quick Start

Use the aim-gateway-domain references to review the external interface rules and the relevant REST/WebSocket/gRPC contract documents before implementing or modifying any gateway-related feature.

Frequently Asked Questions about aim-gateway-domain

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce a REST API gateway boundary to prevent internal services from exposing public endpoints?

To enforce a REST API gateway boundary, you must ensure only the gateway domain publishes public REST and WebSocket ports, while other domains remain internal using gRPC and Kafka orchestration to prevent accidental endpoint leakage.

What is the best way to design a WebSocket frame contract for messaging, presence, and typing notifications?

Designing a WebSocket frame contract involves centralizing gateway responsibilities for messaging, presence, typing, and client notification semantics, while ensuring schema fields align with underlying gRPC push events for consistent client-facing contracts.

How do I validate that my microservices only use internal gRPC and Kafka instead of publishing REST ports?

You can validate internal microservices by applying interface boundary constraints that restrict non-gateway domains from publishing REST or WebSocket ports, ensuring they rely strictly on internal gRPC and Kafka orchestration.

Does this gateway domain governance approach handle authentication proxying and attachment uploads?

Yes, gateway domain governance explicitly handles authentication proxying and attachment uploads by centralizing REST proxy boundaries and WebSocket frame responsibilities within the external interface contract documentation.

When do I need protocol governance for evolving a client-facing API schema?

You need protocol governance when evolving client-facing API schemas to track changes like friend tags, unified search, read receipts, and typing pipelines, ensuring updates maintain consistency across REST and WebSocket protocols.