Schobo

Stop naming chaos before it lands in production.

Schobo is a lightweight, configurable toolkit that helps teams enforce consistent JSON key naming and validate JSON payloads against agreed contracts. It is designed for engineering teams who exchange JSON between microservices, APIs, chatbots, data pipelines, and integration layers.

Schobo ensures:

• Consistent and predictable JSON field naming
• Early detection of breaking changes in pull requests
• Runtime validation of JSON payloads against downstream schemas
• A shared, versioned contract between teams

🚀 What Is Schobo?

Schobo solves one of the most common sources of production issues:
inconsistent JSON field naming and mismatched payload structures between services.

It provides two core capabilities:

🔤 1. PR-Time Naming Linting

Automatically checks JSON files in pull requests to ensure key names follow the naming style your team has chosen, such as:

• camelCase
• snake_case
• PascalCase
• UPPER_CASE
• kebab-case
• UPPER_SNAKE_CASE

Schobo flags naming issues early and suggests corrected field names.

🧪 2. Runtime JSON Payload Validation

Schobo validates actual JSON payloads during application runtime using a downstream schema contract (powered by AJV).

Perfect for:

• Microservices exchanging event payloads
• Chatbot and AI context validation
• API request/response validation
• Ensuring compatibility between services
• Data quality gates

⚙️ Configuration — .schobo.yml

Schobo is driven by a simple YAML configuration file:

pr_time_validation: true runtime_validation: true

lint_rules: style: camelCase forbidden: - ' ' # No spaces in keys

schemas_folder_pr: schemas/pr-lint schemas_folder_runtime: schemas/runtime contracts_folder: contracts

📦 CLI Usage

Lint JSON field names (PR-time)

schobo lint schemas/pr-lint

Validate runtime payloads against contracts

schobo validate contracts/downstream-schema.json schemas/runtime

🏗 Architecture Overview (Plain Text)

Developer opens a Pull Request
↓
Schobo automatically runs schobo lint
↓
Any inconsistent JSON keys are flagged
↓
PR is approved and merged
↓
At runtime, the application runs schobo validate
↓
JSON payloads are checked against downstream contracts

📘 Examples

PR-Time Naming Linting Example

Given JSON:

{ "first_name": "Alice", "lastName": "Smith", "POSTAL_CODE": "12345" }

Output:

❌ first_name → suggest: firstName
❌ POSTAL_CODE → suggest: postalCode

Runtime Validation Example

Contract:

{ "type": "object", "required": ["PROVIDER", "BOT_NAME"], "properties": { "PROVIDER": { "type": "string" }, "BOT_NAME": { "type": "string" } } }

Payload:

{ "PROVIDER": "WEBSOCKET", "BOT_NAME": "websocket-service-1" }

Running:

schobo validate contracts/downstream-schema.json schemas/runtime

Output:

All files passed JSON Schema validation!

🚦 CI Integration (GitHub Actions)

name: Schobo Validation

on: pull_request: paths: - 'schemas/**' workflow_dispatch:

jobs: pr_lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '20' - run: npm install - run: npm run build - run: npm install -g . - name: Run PR Linting run: schobo lint schemas/pr-lint

runtime_validation: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '20' - run: npm install - run: npm run build - run: npm install -g . - name: Run JSON Validation run: schobo validate contracts/downstream-schema.json schemas/runtime

🧩 Using Schobo at Application Runtime

import { validateSchemaPath } from "schobo/runtime";

await validateSchemaPath( "contracts/downstream-schema.json", "schemas/runtime" );

If validation fails, Schobo reports:

• Missing required fields
• Type mismatches
• Location of the failing field
• The schema rule that was violated

📄 Managing JSON Schema Contracts

1. Store all schemas in contracts/
2. Version them:
   • downstream-schema.v1.json
   • downstream-schema.v2.json
3. Require contract reviewer approval from both producer and consumer teams
4. Announce schema changes via release notes or docs

🤝 Contributing

1. Fork the repo
2. Create a feature branch
3. Run npm test
4. Ensure PR linting passes
5. Open a PR

📜 License

MIT License — free for commercial and open-source use.