<p style="text-align:center;" align="center"><a href="https://meshery.io"><picture>
 <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/meshery/meshery/master/.github/assets/images/readme/meshery-logo-light-text-side.svg">
 <source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/meshery/meshery/master/.github/assets/images/readme/meshery-logo-dark-text-side.svg">
<img src="https://raw.githubusercontent.com/meshery/meshery/master/.github/assets/images/readme/meshery-logo-dark-text-side.svg"
alt="Meshery Logo" width="70%" /></picture></a><br /><br /></p>
<p align="center">
<a href="https://hub.docker.com/r/meshery/meshery" alt="Docker pulls">
  <img src="https://img.shields.io/docker/pulls/meshery/meshery.svg" /></a>
<a href="https://github.com/issues?q=is%3Aopen%20is%3Aissue%20archived%3Afalse%20(org%3Ameshery%20OR%20org%3Aservice-mesh-performance%20OR%20org%3Aservice-mesh-patterns%20OR%20org%3Ameshery-extensions)%20label%3A%22help%20wanted%22" alt="GitHub issues by-label">
  <img src="https://img.shields.io/github/issues/meshery/meshery/help%20wanted.svg?color=informational" /></a>
<a href="https://github.com/meshery/meshery/blob/master/LICENSE" alt="LICENSE">
  <img src="https://img.shields.io/github/license/meshery/meshery?color=brightgreen" /></a>
<a href="https://artifacthub.io/packages/helm/meshery/meshery" alt="Artifact Hub Meshery">
  <img src="https://img.shields.io/endpoint?color=brightgreen&label=Helm%20Chart&style=plastic&url=https%3A%2F%2Fartifacthub.io%2Fbadge%2Frepository%2Fartifact-hub" /></a>
<a href="https://goreportcard.com/report/github.com/meshery/meshery" alt="Go Report Card">
  <img src="https://goreportcard.com/badge/github.com/meshery/meshery" /></a>
<a href="https://github.com/meshery/meshery/actions" alt="Build Status">
  <img src="https://img.shields.io/github/actions/workflow/status/meshery/meshery/release-drafter.yml" /></a>
<a href="https://bestpractices.coreinfrastructure.org/projects/3564" alt="CLI Best Practices">
  <img src="https://bestpractices.coreinfrastructure.org/projects/3564/badge" /></a>
<a href="http://discuss.meshery.io" alt="Discuss Users">
  <img src="https://img.shields.io/discourse/users?label=discuss&logo=discourse&server=https%3A%2F%2Fdiscuss.meshery.io" /></a>
<a href="https://slack.meshery.io" alt="Join Slack">
  <img src="https://img.shields.io/badge/Slack-@meshery.svg?logo=slack" /></a>
<a href="https://twitter.com/intent/follow?screen_name=mesheryio" alt="Twitter Follow">
  <img src="https://img.shields.io/twitter/follow/mesheryio.svg?label=Follow+Meshery&style=social" /></a>
<a href="https://github.com/meshery/meshery/releases" alt="Meshery Downloads">
  <img src="https://img.shields.io/github/downloads/meshery/meshery/total" /></a>
<!-- <a href="https://app.fossa.com/projects/git%2Bgithub.com%2Fmeshery%2Fmeshery?ref=badge_shield" alt="License Scan Report">
  <img src="https://app.fossa.com/api/projects/git%2Bgithub.com%2Fmeshery%2Fmeshery.svg?type=shield"/></a>
  -->
</p>

<h5><p align="center"><i>If you’re using Meshery or if you like the project, please <a href="https://github.com/meshery/meshery/stargazers">★</a> this repository to show your support! 🤩</i></p></h5>

# Meshery Schemas

Meshery follows schema-driven development. As a project, Meshery has different types of schemas. Some schemas are external facing, and some internal to Meshery itself. This repository serves as a central location for storing schemas from which all Meshery components can take reference.

Meshery schemas offer a powerful system designed for:

- **Model-Driven Management:** Meshery uses explicit models for describing infrastructure and applications.
- **Dynamic Discovery:** The ability to process different kinds of relationships and styles, enables a sophisticated system that can adapt to many configurations.
- **Lifecycle Management:** The schema properties track status and lifecycle of resources.
- **Extensibility:** Open-ended metadata and modular schema components enable expansion and customization.
- **Visual Representation:** The properties for styling of edges and nodes is for creating a user friendly visual representation.
- **Automated Operations:** The schemas can support validation and automated configuration of infrastructure and applications, and patching.

For an explanation of Meshery's terminology regarding schemas, definitions, declarations, and instances, please see [Contributor's Guide to Models](https://docs.meshery.io/project/contributing/contributing-models).

For identifier-naming rules (wire casing, DB tag separation, URL/path/query-param conventions, operationId form), see [`docs/identifier-naming-contributor-guide.md`](docs/identifier-naming-contributor-guide.md) — the canonical, reader-friendly directory for the camelCase-on-the-wire contract that this repository and every downstream consumer share.

## Contributing
--> **For an explanation of the directory structure of this repository and how to contribute changes to Meshery's schemas, see [Contributor's Guide to Schema-Driven Development](https://docs.meshery.io/project/contributing/contributing-schemas).**

<p style="clear:both;">&nbsp;</p>

## Join the Meshery community!

<a name="contributing"></a><a name="community"></a>
Our projects are community-built and welcome collaboration. 👍 Be sure to see the <a href="https://docs.meshery.io/project/contributing#not-sure-where-to-start">Contributor Welcome Guide</a> and <a href="https://meshery.io/community#handbook">Community Handbook</a> for a tour of resources available to you. Jump into community <a href="https://slack.meshery.io">Slack</a> or <a href="https://discuss.meshery.io">discussion forum</a> to participate.

<p style="clear:both;">
<h3>Find your MeshMate</h3>

<p>MeshMates are experienced community members, who will help you learn your way around, discover live projects, and expand your community network. Connect with a Meshmate today!</p>

Find out more on the <a href="https://meshery.io/community#meshmates">Meshery community</a>. <br />

</p>
<br /><br />
<div style="display: flex; justify-content: center; align-items:center;">
<div>
<a href="https://meshery.io/community"><img alt="Meshery Cloud Native Community" src="https://raw.githubusercontent.com/meshery/meshery/master/.github/assets/images/readme/community.png" width="140px" style="margin-right:36px; margin-bottom:7px;" width="140px" align="left"/></a>
</div>
<div style="width:60%; padding-left: 16px; padding-right: 16px">
<p>
✔️ <em><strong>Join</strong></em> any or all of the weekly meetings on <a href="https://meshery.io/calendar">community calendar</a>.<br />
✔️ <em><strong>Watch</strong></em> community <a href="https://www.youtube.com/@mesheryio?sub_confirmation=1">meeting recordings</a>.<br />
✔️ <em><strong>Fill-in</strong></em> a <a href="https://meshery.io/newcomers">community member form</a> to gain access to community resources.
<br />
✔️ <em><strong>Discuss</strong></em> in the <a href="https://discuss.meshery.io">Community Forum</a>.<br />
✔️ <em><strong>Explore more</strong></em> in the <a href="https://meshery.io/community#handbook">Community Handbook</a>.<br />
</p>
<p align="center">
<i>Not sure where to start?</i> Grab an open issue with the <a href="https://github.com/issues?q=is%3Aopen%20is%3Aissue%20archived%3Afalse%20(org%3Ameshery%20OR%20org%3Aservice-mesh-performance%20OR%20org%3Aservice-mesh-patterns%20OR%20org%3Ameshery-extensions)%20label%3A%22help%20wanted%22">help-wanted label</a>.
</p>
</div>
<div>&nbsp;</div>

## Contributing

Please do! We're a warm and welcoming community of open source contributors. All types of contributions are welcome. Please read:

- [General Contributor Guide](https://docs.meshery.io/project/contributing) - Overview of contribution processes
- [Schema Contributor Guide](./CONTRIBUTING.md) - Schema-specific development workflows and guidelines

<div>&nbsp;</div>


# 🧬 Schema-Driven Development Guide

Meshery follows a **Schema-Driven Development (SDD)** approach. This means that the **structure of data** used throughout the system is centrally defined using **schemas**. These schemas power consistency, validation, and code generation across the Meshery platform.

---

## 🧾 Schema Definition in Meshery

Meshery uses the **OpenAPI v3** specification to define and manage schemas. Given the complexity of the platform, Meshery adopts a **modular, versioned, and extensible** schema strategy:

* ✅ **Versioned schemas** for backward compatibility.
* 🧩 **Modular constructs** for maintainability and reuse.
* 🧪 **Schemas are used** for validation, API documentation, and automatic code generation.

> 💡 **TIP**: When referencing models or other constructs in the schema, **always add `x-go-type` and `x-go-import-path`** to avoid generating redundant Go structs. Refer to existing patterns in the codebase.

---

## 📁 Schema Directory Structure

All schemas are located in the `schemas/` directory at the root of the Meshery repository:

```
schemas/
  constructs/
    <schema-version>/               # e.g., v1beta1
      <construct>/                  # e.g., model, component
        api.yml                     # Index file: references all subschemas + defines API endpoints
        <construct>.yaml            # Subschema: data model definition for the construct
        <other_subschema>.yaml      # Additional subschemas (optional)
        templates/                  # Manually defined templates directory
          <construct>_template.json # JSON template from schema
          <construct>_template.yaml # YAML template from schema
          <variant>_template.json   # Additional variant templates (optional)
  
  typescript/                       # TypeScript source and generated files
    index.ts                        # Manually maintained - public API surface
    generated/                      # Auto-generated (do NOT commit)
      <schema-version>/
        <construct>/
          <Construct>.d.ts          # TypeScript type definitions
          <Construct>Schema.ts      # OpenAPI schema as JS object
    rtk/                            # RTK Query client configurations
      cloud.ts
      meshery.ts
  
  dist/                             # Built distribution (do NOT commit)
    index.js, index.d.ts
    cloudApi.js, mesheryApi.js
    constructs/                     # Built schema exports (renamed from 'generated')
      <schema-version>/<construct>/<Construct>Schema.js
  
  models/                           # Auto-generated Go code (do NOT commit)
    <schema-version>/
      <construct>/
        <construct>.go
```

### 🧠 Explanation

* **`constructs/`** – Holds schemas for various versions.
  * **`<schema-version>/`** – Represents a version (e.g., `v1alpha2`, `v1beta1`).
    * **`<construct>/`** – A directory to contain all files for any given construct like `pattern`, `component`, etc.
      * **`api.yml`** – The **index file** for the construct. This file:
        1. References all subschemas (via `$ref`) to bundle them together
        2. Defines all **API endpoints** (REST operations: GET, POST, PUT, DELETE) for the construct
        3. Serves as the entry point for code generation tools (oapi-codegen, openapi-typescript)
      * **`<construct>.yaml`** – A **subschema** that defines the data model (noun) for the construct. Contains the schema properties, types, and validation rules.
      * **Other `.yaml` files** – Additional subschemas can be defined in separate files (e.g., `model_core.yml`, `component_metadata.yml`) and referenced from `api.yml`.
      * **`templates/`** – A subdirectory containing manually defined template files. You can add as many different templates here for different variants, use cases, or configurations. Templates are example instances of the schema with default or sample values.
        * `<construct>_template.json` / `<construct>_template.yaml` – Default templates in JSON/YAML format.
        * Additional variant templates can be added (e.g., `<construct>_minimal_template.json`, `<construct>_full_template.yaml`) for different use cases.

---

## Schema Design Principles: The Dual-Schema Pattern

Every persisted entity in Meshery follows a strict two-schema contract. Violating this contract causes generated Go structs and API clients to be incorrect.

### Rule 1 — Entity schema = response schema only

The `<construct>.yaml` file represents the **full server-side object** as returned in API responses. It must:

- Include **all** server-generated fields: `id`, `created_at`, `updated_at`, `deleted_at`
- List server-generated required fields in `required` (they are always present in responses)
- Have `additionalProperties: false` at the top level

```yaml
# keychain.yaml — response schema ✅
type: object
additionalProperties: false
required:
  - id
  - name
  - owner
  - created_at
  - updated_at
properties:
  id:
    $ref: ../../v1alpha1/core/api.yml#/components/schemas/uuid
  name:
    type: string
  owner:
    $ref: ../../v1alpha1/core/api.yml#/components/schemas/uuid
  created_at:
    $ref: ../../v1alpha1/core/api.yml#/components/schemas/created_at
  updated_at:
    $ref: ../../v1alpha1/core/api.yml#/components/schemas/updated_at
  deleted_at:
    $ref: ../../v1alpha1/core/api.yml#/components/schemas/nullTime
```

### Rule 2 — Write operations use a separate `*Payload` schema

Every entity that supports `POST` or `PUT` must define a dedicated `{Entity}Payload` schema in `api.yml`. The payload schema:

- Contains **only client-settable fields** (no `created_at`, `updated_at`, `deleted_at`)
- Makes `id` optional with `omitempty` for upsert patterns, or omits it entirely for create-only
- Is referenced by `requestBody` in `POST`/`PUT` operations
- Is **never** reused as a response body

```yaml
# In api.yml — write schema ✅
components:
  schemas:
    KeychainPayload:
      type: object
      description: Payload for creating or updating a keychain.
      required:
        - name
      properties:
        id:
          $ref: ../../v1alpha1/core/api.yml#/components/schemas/uuid
          description: Existing keychain ID for updates; omit on create.
          x-oapi-codegen-extra-tags:
            json: "id,omitempty"
        name:
          type: string
          description: Name of the keychain.
        owner:
          $ref: ../../v1alpha1/core/api.yml#/components/schemas/uuid
          description: Owner UUID; set server-side from auth context if omitted.
          x-oapi-codegen-extra-tags:
            json: "owner,omitempty"

paths:
  /api/auth/keychains:
    post:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/KeychainPayload"   # ← Payload, not Keychain
      responses:
        "200":
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Keychain"        # ← Full entity in response
```

### Rule 3 — Never use the entity schema as a POST/PUT request body

Using the full entity schema as a `requestBody` forces clients to supply server-generated fields (`id`, `created_at`, `updated_at`) and produces incorrect generated client code.

```yaml
# ❌ Wrong — exposes server-generated required fields to clients
post:
  requestBody:
    content:
      application/json:
        schema:
          $ref: "#/components/schemas/Keychain"

# ✅ Correct — separate payload type for writes
post:
  requestBody:
    content:
      application/json:
        schema:
          $ref: "#/components/schemas/KeychainPayload"
```

### Checklist when adding a new entity

- [ ] `<construct>.yaml` has `additionalProperties: false`
- [ ] `<construct>.yaml` lists all server-generated fields in `properties` and `required`
- [ ] `api.yml` defines a `{Construct}Payload` schema with only client-settable fields
- [ ] All `POST`/`PUT` `requestBody` entries reference `{Construct}Payload`, not `{Construct}`
- [ ] `GET` responses reference the full `{Construct}` entity schema

---

## Naming Conventions

> This section is the inline authority; for the reader-friendly directory (26-row naming table with before/after and do/don't examples), see [`docs/identifier-naming-contributor-guide.md`](docs/identifier-naming-contributor-guide.md).

- Property names
  - Use camelCase for property fields (e.g., `schemaVersion`, `displayName`, `componentsCount`).
  - Identifier fields use lowerCamelCase with "Id" suffix (e.g., `modelId`, `registrantId`, `categoryId`).
  - Enums use lowercase words (e.g., `enabled`, `ignored`, `duplicate`).
  - Use singular nouns for object names (e.g., `model`, `component`, `design`).

- OpenAPI schema names
  - PascalCase nouns under `components/schemas` (e.g., `Model`, `Component`).
  - Files/folders are lowercase: `api.yml` (index), `<construct>.yaml` (subschemas), `templates/<construct>_template.(json|yaml)`.

- Endpoints and operations
  - Paths are under `/api` with kebab-case , plural nouns (e.g., `/api/workspaces`, `/api/environments`).
  - Path params are camelCase  (e.g., `{subscriptionId}`, `{connectionId}`).
  - Non-CRUD actions append a verb segment (e.g., `.../register`, `.../export`, `.../cancel`); legacy lowerCamelCase may appear (e.g., `.../upgradePreview`).
  - `operationId` is camelCase VerbNoun (e.g., `registerMeshmodels`).

- Versioning
  - `schemaVersion` uses group/version (e.g., `models.meshery.io/v1beta1`, `components.meshery.io/v1beta1`).
  - Version strings follow k8s-style (`v1`, `v1alpha1`, `v1beta1`); semver fields use standard SemVer.

---

## 🔧 Go Helper Files

While Go structs are auto-generated from schemas, you often need to add **custom methods** to make these structs compatible with databases, implement interfaces, or add utility functions. This is done through manually created **helper files**.

### When to Create Helper Files

Create a helper file (`*_helper.go` or `helpers.go`) in the generated package when you need:

1. **SQL Driver Compatibility** - Implement `database/sql/driver.Scanner` and `driver.Valuer` interfaces
2. **Entity Interface Implementation** - Implement the `entity.Entity` interface for database operations
3. **GORM Table Names** - Define custom table names via `TableName()` method
4. **Utility Methods** - Add helper functions for serialization, validation, or business logic
5. **Type Conversions** - Add methods to convert between related types

### Helper File Location

```
models/
├── core/
│   ├── core.go                    # Auto-generated (do NOT edit)
│   ├── helpers.go                 # Manual: utility functions
│   ├── datatype_map.go            # Manual: Map type with SQL driver methods
│   └── datatype_null_time.go      # Manual: NullTime with SQL driver methods
├── v1beta1/
│   ├── model/
│   │   ├── model.go               # Auto-generated (do NOT edit)
│   │   └── model_helper.go        # Manual: Entity interface, TableName, etc.
│   ├── component/
│   │   ├── component.go           # Auto-generated (do NOT edit)
│   │   └── component_helper.go    # Manual: Entity interface, TableName, etc.
│   └── category/
│       ├── category.go            # Auto-generated (do NOT edit)
│       └── category_helper.go     # Manual: Entity interface, TableName, etc.
```

### SQL Driver Interface Implementation

To store complex types in SQL databases, implement `Scan` and `Value` methods:

```go
// helpers.go - This is NOT autogenerated
package mypackage

import (
    "database/sql/driver"
    "encoding/json"
    
    "github.com/meshery/schemas/models/core"
)

// Scan implements sql.Scanner interface for reading from database
func (m *MyComplexType) Scan(value interface{}) error {
    mapVal := core.Map{}
    err := mapVal.Scan(value)
    if err != nil {
        return err
    }
    return core.MapToStruct(mapVal, m)
}

// Value implements driver.Valuer interface for writing to database
func (m MyComplexType) Value() (driver.Value, error) {
    mapVal, err := core.StructToMap(m)
    if err != nil {
        return nil, err
    }
    return core.Map(mapVal).Value()
}
```

### Entity Interface Implementation

For structs that need database CRUD operations, implement the `entity.Entity` interface:

```go
// component_helper.go - This is NOT autogenerated
package component

import (
    "fmt"
    
    "github.com/gofrs/uuid"
    "github.com/meshery/meshkit/database"
    "github.com/meshery/meshkit/models/meshmodel/entity"
    "gorm.io/gorm/clause"
)

// TableName returns the database table name for GORM
func (c ComponentDefinition) TableName() string {
    return "component_definition_dbs"
}

// Type returns the entity type identifier
func (c ComponentDefinition) Type() entity.EntityType {
    return entity.ComponentDefinition
}

// GenerateID generates a new UUID for the entity
func (c *ComponentDefinition) GenerateID() (uuid.UUID, error) {
    return uuid.NewV4()
}

// GetID returns the entity's ID
func (c ComponentDefinition) GetID() uuid.UUID {
    return c.Id
}

// GetEntityDetail returns a human-readable description
func (c *ComponentDefinition) GetEntityDetail() string {
    return fmt.Sprintf("type: %s, name: %s, model: %s", 
        c.Type(), c.DisplayName, c.Model.Name)
}

// Create inserts the entity into the database
func (c *ComponentDefinition) Create(db *database.Handler, hostID uuid.UUID) (uuid.UUID, error) {
    c.Id, _ = c.GenerateID()
    err := db.Omit(clause.Associations).Create(&c).Error
    return c.Id, err
}

// UpdateStatus updates the entity's status in the database
func (c *ComponentDefinition) UpdateStatus(db *database.Handler, status entity.EntityStatus) error {
    return nil
}
```

### Core Utility Types

The `models/core/` package provides reusable types with built-in SQL compatibility:

| Type | Purpose | Use Case |
|------|---------|----------|
| `core.Map` | `map[string]any` with SQL support | Storing JSON objects in database |
| `core.NullTime` | Nullable time with JSON/YAML support | Optional timestamp fields |
| `core.Time` | Time wrapper with custom formatting | Required timestamp fields |

### Example: Using Core Types

```go
// In your helper file
package mypackage

import "github.com/meshery/schemas/models/core"

// For nullable timestamps (e.g., deleted_at)
type MyStruct struct {
    DeletedAt core.NullTime `json:"deleted_at" gorm:"column:deleted_at"`
}

// For JSON metadata stored as blob
type MyStruct struct {
    Metadata core.Map `json:"metadata" gorm:"type:bytes;serializer:json"`
}
```

### Important Notes

1. **File Header Comment**: Always add `// This is not autogenerated.` at the top of helper files
2. **Same Package**: Helper files must be in the same package as the generated code
3. **Do Commit Helper Files**: Unlike generated `.go` files, helper files ARE committed to the repository
4. **Mutex for Creation**: Use sync.Mutex when implementing `Create()` to prevent race conditions

---

## ⚙️ Code Generation

Meshery supports **automated code generation** from schemas for:

* **Go**: Strongly-typed models for backend → `models/<version>/<package>/`
* **TypeScript Types**: Interfaces and type definitions → `typescript/generated/<version>/<package>/<Package>.d.ts`
* **TypeScript Schemas**: OpenAPI schemas as const JS objects → `typescript/generated/<version>/<package>/<Package>Schema.ts`
* **RTK Query**: Clients generated from OpenAPI for use with Redux → `typescript/rtk/`
* **JSON/YAML**: Templates with defaults and resolved references.

### TypeScript Schema Exports

Each construct's OpenAPI schema is exported as a const JavaScript object for runtime use:

```typescript
// Import from main index
import {
  ModelDefinitionV1Beta1OpenApiSchema,
  ComponentDefinitionV1Beta1OpenApiSchema,
  DesignDefinitionV1Beta1OpenApiSchema,
} from "@meshery/schemas";

// Or import individual schemas directly
import ModelSchema from "@meshery/schemas/dist/constructs/v1beta1/model/ModelSchema";
import ComponentSchema from "@meshery/schemas/dist/constructs/v1beta1/component/ComponentSchema";
```

### TypeScript Type Namespaces

Types are organized by version in namespaces:

```typescript
import { v1beta1, v1alpha1 } from "@meshery/schemas";

const component: v1beta1.Component = { /* ... */ };
const model: v1beta1.Model = { /* ... */ };
const design: v1beta1.Design = { /* ... */ };
```

---

## 🚀 Unified Build: One Command for Everything

Use the following command to perform the **entire schema-driven generation workflow**:

```bash
make build
npm run build  # Build TypeScript distribution with tsup
```

### 🔧 What `make build` does:

1. **Bundles OpenAPI schemas** for:

   * Meshery
   * Remote Providers (e.g. Meshery Cloud)
   * Combined (all constructs)
   
2. **Generates:**

   * Golang structs → `models/`
   * TypeScript type definitions (`.d.ts`) → `typescript/generated/`
   * TypeScript schema exports (`*Schema.ts`) → `typescript/generated/`
   * RTK Query clients → `typescript/rtk/`

3. **After `npm run build`:**

   * Builds distribution files → `dist/`
   * Creates CJS and ESM bundles
   * Generates declaration files

> ⚠️ This is the recommended way to stay in sync with schema changes.

---

## 🧱 Bundled Schema Outputs

After running `make build`, three bundled schema files are created:

| File                 | Purpose                                        |
| -------------------- | ---------------------------------------------- |
| `merged_schema.yml`  | All schemas combined (used by Meshery clients) |
| `cloud_schema.yml`   | Cloud-specific APIs for Remote Providers (e.g. Meshery Cloud) |
| `meshery_schema.yml` | Meshery-specific APIs                          |

---

## ✍️ Annotating OpenAPI Paths

To control which schema paths are included in each bundled output, use the `x-internal` annotation inside the OpenAPI operations (`get`, `post`, etc.). The annotation is **required on every operation** — `validate-schemas` (Rule 14) and the bundler both reject operations that omit it.

### Example:

```yaml
paths:
  /api/entitlement/plans:
    get:
      x-internal: ["cloud"]
      operationId: getPlans
      tags:
        - Plans
      summary: Get all plans supported by the system
      responses:
        "200":
          description: Plans fetched successfully
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/Plan"
```

* `x-internal: ["cloud"]` — included in the cloud bundle only.
* `x-internal: ["meshery"]` — included in the meshery bundle only.
* `x-internal: ["cloud", "meshery"]` — included in **both** bundles.

---

### `x-generate-db-helpers`

Use `x-generate-db-helpers: true` as a **schema-level** annotation (not per-property) on a named component under `components/schemas` to instruct the Go generator to automatically produce SQL driver helper methods (`Scan` and `Value`) for that type.

**When to use it**: The annotated schema type must satisfy both conditions:

1. It has a **dedicated OpenAPI schema definition** (i.e., it is a named component with explicit properties, not a generic map).
2. It is **persisted as a JSON blob** in a single database column — not spread across a dedicated table with one column per field.

**When NOT to use it**: Do not annotate amorphous types that have no fixed schema definition (e.g., a generic `metadata` object). Those fields should use `x-go-type: "core.Map"` instead. Also do not annotate types that map to full database tables with individual columns for each property — those are handled by the normal DB tag generation.

#### Example

```yaml
components:
  schemas:
    Quiz:
      x-generate-db-helpers: true   # ← schema-level; not on individual properties
      type: object
      required:
        - id
        - title
      properties:
        id:
          $ref: "../../v1alpha1/core/api.yml#/components/schemas/uuid"
        title:
          type: string
```

The generator produces `zz_generated.helpers.go` containing:

```go
func (value *Quiz) Scan(src interface{}) error {
    if src == nil {
        *value = Quiz{}
        return nil
    }
    mapVal := core.Map{}
    if err := mapVal.Scan(src); err != nil {
        return err
    }
    return core.MapToStruct(mapVal, value)
}

func (value Quiz) Value() (driver.Value, error) {
    mapVal, err := core.StructToMap(value)
    if err != nil {
        return nil, err
    }
    return core.Map(mapVal).Value()
}
```

These implement Go's `sql.Scanner` and `driver.Valuer` interfaces so the struct is transparently serialized as JSON when reading from or writing to a database column.

**Counter-example — `metadata`**: A `metadata` field stored as JSON in the database is intentionally *not* annotated with `x-generate-db-helpers` because it is amorphous — it has no fixed property list. Use `x-go-type: "core.Map"` for those fields instead:

```yaml
metadata:
  type: object
  additionalProperties: true
  x-go-type: "core.Map"
  x-go-type-skip-optional-pointer: true
  x-oapi-codegen-extra-tags:
    db: "metadata"
```

---

## 🛠️ Advanced Usage (Optional)

### 📌 Custom Generation in `generate.sh`

Meshery uses a helper script (`generate.sh`) to map schema constructs to generated output:

```bash
generate_schema_models <construct> <schema-version> [<openapi-file>]

generate_schema_models "capability" "v1alpha1"
generate_schema_models "category" "v1beta1"
generate_schema_models "pattern" "v1beta1" "schemas/constructs/v1beta1/design/api.yml"
```

This maps to Go packages like:

```
models/v1alpha1/capability/capability.go
```

### 🧩 RTK Query Client Generation

The OpenAPI bundle is passed to a codegen tool to generate RTK Query clients. Include relevant paths using `x-internal` annotations and define request/response schemas appropriately.

You can build the OpenAPI bundles with:

```bash
# Build per-construct bundles, merge them, and emit cloud/meshery OpenAPI specs
make bundle-openapi
```

# Using Generated RTK Query Clients


## Prerequisites

Before using the generated RTK clients, ensure you have:

1. Installed the required dependencies:
   - `@reduxjs/toolkit`
   - `@meshery/schemas`

2. Set up environment variables:
   - `RTK_CLOUD_ENDPOINT_PREFIX`: Base URL for Cloud API endpoints
   - `RTK_MESHERY_ENDPOINT_PREFIX`: Base URL for Meshery API endpoints

## Store Configuration

### Import API Slices Correctly

To avoid cyclical imports that can break your application, import API slices from their specific exports:

```javascript
// ✅ Correct: Import from specific API exports
import { cloudApi as cloudBaseApi } from "@meshery/schemas/dist/cloudApi";
import { mesheryApi } from "@meshery/schemas/dist/mesheryApi";

// ❌ Incorrect: Do not import directly from generic API file
// import { api } from "@meshery/schemas/dist/api"; // Can cause cyclical imports
```

### Configure Redux Store

Add the API reducers and middleware to your Redux store configuration:

```javascript
import { combineReducers, configureStore } from "@reduxjs/toolkit";
import { cloudApi as cloudBaseApi } from "@meshery/schemas/dist/cloudApi";
import catalogReducer from "./slices/catalog";
import connectionReducer from "./slices/connection";
import organizationReducer from "./slices/organization";
import chartReducer from "./slices/charts";
import themeReducer from "./slices/theme";
// Optional: If you have locally defined APIs
import { cloudApi } from "../api";

// Combine reducers
const rootReducer = combineReducers({
  catalog: catalogReducer,
  charts: chartReducer,
  organization: organizationReducer,
  connection: connectionReducer,
  theme: themeReducer,
  // Add generated API reducers
  [cloudBaseApi.reducerPath]: cloudBaseApi.reducer,
  // Optional: Add locally defined API reducers
  [cloudApi.reducerPath]: cloudApi.reducer
});

// Configure store with middleware
export const store = configureStore({
  reducer: reduxPersist.createPersistEnhancedReducer(rootReducer),
  middleware: getDefaultMiddleware =>
    getDefaultMiddleware()
      // Add generated API middleware
      .concat(cloudBaseApi.middleware)
      // Optional: Add locally defined API middleware
      .concat(cloudApi.middleware)
      // Add persistence middleware if needed
      .concat(reduxPersist.persistMiddleware)
});

// Set up listeners for RTK Query cache behaviors like refetchOnFocus/refetchOnReconnect
setupListeners(store.dispatch);
```

## Using API Hooks

After configuring your store, you can import and use the generated hooks:

### Cloud API Hooks

```javascript
import {
  useGetPlansQuery,
  useCreateDesignMutation,
  useGetDesignsQuery,
  // Other cloud API hooks...
} from "@meshery/schemas/dist/cloudApi";

function MyComponent() {
  // Use hooks directly in your components
  const { data: plans, isLoading, error } = useGetPlansQuery();

  // Handle loading states
  if (isLoading) return <div>Loading plans...</div>;

  // Handle errors
  if (error) return <div>Error loading plans</div>;

  // Use data
  return (
    <div>
      {plans.map(plan => (
        <div key={plan.id}>{plan.name}</div>
      ))}
    </div>
  );
}
```

### Meshery API Hooks

```javascript
import {
  useGetMeshModelsQuery,
  useSubmitMeshConfigMutation,
  // Other Meshery API hooks...
} from "@meshery/schemas/dist/mesheryApi";

function MesheryComponent() {
  const { data: meshModels } = useGetMeshModelsQuery();
  // ...
}
```

## Troubleshooting

### Common Issues

1. **Stuck Loading States**:
   - Verify environment variables are correctly set
   - Check for CORS issues
   - Ensure proper authentication headers are included

2. **Cyclical Imports**:
   - Always import from specific API files (`cloudApi.ts`, `mesheryApi.ts`)
   - Avoid importing from generic `api.ts` files

3. **Multiple RTK Instances**:
   - Ensure proper reducer and middleware registration
   - Check for naming conflicts in reducerPaths

### Redux DevTools

For better debugging, use Redux DevTools to monitor:
- API request lifecycles
- State changes
- Caching behavior

## Best Practices

1. **Handle Loading States**:
   ```javascript
   const { data, isLoading, isFetching, error } = useGetDataQuery();
   ```

2. **Leverage Cache Options**:
   ```javascript
   const { data } = useGetDataQuery(null, {
     pollingInterval: 30000, // Re-fetch every 30 seconds
     refetchOnMountOrArgChange: true,
     skip: !isReady // Skip query when not ready
   });
   ```

3. **Use Transformations When Needed**:
   ```javascript
   const transformedData = data?.map(item => ({
     ...item,
     formattedValue: formatValue(item.value)
   }));
   ```

## 🧪 Testing & Validating Schemas

Validate your schema updates before committing by running:

```bash
make build
```

For repository validation checks:

```bash
make validate-schemas
```

### Schema Validation Modes

The `validation/` Go package (invoked via `go run ./cmd/validate-schemas`) enforces 41 rules organized into four issue tiers. Different `make` targets control which tiers are visible and whether violations block the build.

| Mode | Command | Blocking | Style | Design | Contract |
| --- | --- | --- | --- | --- | --- |
| Build default | `make validate-schemas` | Exit 1 | Silent | Silent | Silent |
| Advisory audit | `make audit-schemas` | Exit 0 | Silent | Visible | Visible |
| Full advisory backlog | `make audit-schemas-full` | Exit 0 | Silent | Visible | Visible |
| Style debt report | `make audit-schemas-style-full` | Exit 0 | Visible | Visible | Visible |
| Full debt report | `make audit-schemas-debt-full` | Exit 0 | Visible | Visible | Visible |
| Strict CI gate | `make validate-schemas-strict` | Exit 1 | Error | Error | Error |

- **Blocking** (Rules 1-2, 5, 11-22, 27, 32-33): Always enforced. Break code generation or violate structural contracts.
- **Style** (Rules 3-4, 6-10, 19): Naming conventions. Silent by default; visible with `--style-debt`; blocking with `--strict-consistency`.
- **Design** (Rules 23-26, 30-31): API design patterns. Visible as advisories in `--warn` mode.
- **Contract** (Rules 28-29): Published API contract checks (response codes, duplicate schemas). Visible as advisories in `--warn` mode.

Run unit tests for the validation logic:

```bash
go test ./validation/...
```

### Build Pipeline

`make build` runs 8 steps in sequence. Each step depends on the previous.

```
schemas/constructs/          (OpenAPI YAML source files)
        |
        v
[1] validate-schemas         go run ./cmd/validate-schemas
        |                    41 rules: casing, dual-schema, templates, pagination
        v
[2] bundle-openapi           node build/bundle-openapi.js
        |                    Per-construct: in-repo dereference to merged-openapi.json
        |                    Merge all: in-repo prefixing merge → merged_openapi.yml
        |                    Filter: cloud_openapi.yml, meshery_openapi.yml
        v
[3] generate-golang          node build/generate-golang.js
        |                    Per-package: oapi-codegen → models/<ver>/<pkg>/<pkg>.go
        |                    Post-processing pipeline (see below)
        v
[4] generate-rtk             node build/generate-rtk.js
        |                    RTK Query clients from bundled OpenAPI specs
        v
[5] generate-ts              npm run generate:types
        |                    openapi-typescript → typescript/generated/<ver>/<pkg>/
        v
[6] generate-permissions     Go + TypeScript permission key generation
        v
[7] build-ts                 npm run build (tsup)
        |                    Bundles TypeScript distribution → dist/
        v
[8] test-golang              go build ./... && go test ./...
```

### Go Generation Pipeline

`build/generate-golang.js` runs a 10-stage pipeline per package. The pipeline generates, transforms, and validates Go structs.

| Stage | Function | What it does |
| --- | --- | --- |
| 1 | `oapi-codegen` | Generates Go structs with `json` tags from schema property names (verbatim) |
| 2 | `addYamlTags()` | Copies each `json` tag value to a `yaml` tag |
| 3 | `removeSelfReferentialAliases()` | Strips `type X = X` aliases when manual definitions exist in same package |
| 4 | `addSchemaExtraTags()` | Merges `db`, `gorm`, etc. from `x-oapi-codegen-extra-tags` into struct tags |
| 5 | `rewriteExternalRefAliases()` | Normalizes import aliases from opaque names to readable ones |
| 6 | `validateReadableImportAliases()` | Verifies no opaque import aliases remain |
| 7 | `addCompatibilityParameterAliases()` | Adds backward-compatible parameter type aliases |
| 8 | `ensureRequiredImports()` | Adds missing Go imports (e.g., `uuid`) when inlined `x-go-type` requires them |
| 9 | `validateGeneratedDbTags()` | Verifies every `db:` tag declared in the schema is present in generated Go |
| 10 | `validateGeneratedJsonTags()` | Verifies every `json:` tag in generated Go matches the schema property name |

The **property name is the single source of truth** for the json wire format. oapi-codegen reads it verbatim (stage 1), and `validateGeneratedJsonTags` confirms it survived the pipeline unchanged (stage 10).

---

## ✅ Summary

| Task                         | Command                          |
| ---------------------------- | -------------------------------- |
| Generate everything          | `make build`                     |
| Build TypeScript dist        | `npm run build`                  |
| Generate Go code only        | `make golang-generate`           |
| Generate TS types + schemas  | `make generate-ts`               |
| Schema validation (blocking) | `make validate-schemas`          |
| Schema audit (advisory)      | `make audit-schemas`             |
| Full schema debt report      | `make audit-schemas-debt-full`   |
| Validation unit tests        | `npm run test:validate-schemas`  |

### Importing Schemas

```typescript
// Via namespaces (types)
import { v1beta1 } from "@meshery/schemas";
const model: v1beta1.Model = { /* ... */ };

// Via schema exports (runtime)
import { ModelDefinitionV1Beta1OpenApiSchema } from "@meshery/schemas";

// Direct schema import
import ModelSchema from "@meshery/schemas/dist/constructs/v1beta1/model/ModelSchema";
```

---

### License

This repository and site are available as open-source under the terms of the [Apache 2.0 License](https://opensource.org/licenses/Apache-2.0).

<p align="center" >
MESHERY IS A CLOUD NATIVE COMPUTING FOUNDATION PROJECT
</p>
