Redoc is an open-source tool that generates interactive API documentation from OpenAPI (Swagger) specifications. It parses OpenAPI definitions (supporting versions 2.0, 3.0, and 3.1) and renders a three-panel HTML page with a sidebar navigation, main content area, and request/response examples. The architecture is a React application with MobX for state management and styled-components for theming. Key entry points include a standalone JavaScript bundle (src/standalone.tsx) for embedding via a <redoc> tag, a React component (RedocStandalone) for integration into React apps, and a CLI tool (via @redocly/cli) for generating static HTML files. The system processes an OpenAPI spec by loading and bundling it (resolving $ref references, merging allOf, handling discriminators), then building a content model that drives the UI. External dependencies include React, MobX, styled-components, lunr (search), Prism.js (syntax highlighting), and marked (markdown rendering). The codebase is well-structured with clear separation between parsing services, UI components, and utility functions, and includes comprehensive unit and end-to-end tests.
go-swagger is a long-lived CLI and library for OpenAPI/Swagger 2.0 tooling, centered on code generation. The `swagger` binary (cmd/swagger) exposes commands for validate, diff, expand, flatten, mixin, serve, init, version, and generate; `swagger generate` produces Go server, client, model, operation, markdown, and CLI code from a Swagger spec. The generation pipeline loads and validates a spec through the go-openapi stack, flattens it, builds an intermediate representation of models/schemas/operations, then renders `.gotmpl` templates into Go source, finishing with a custom lightweight Go formatter and import sorting. The generated servers and clients depend on go-openapi runtime packages and can embed the spec and serve API docs. The tool also shells out to the Go toolchain at runtime, which is why the Docker image includes Go.
This repository is a CLI tool (`api-platform`) that scaffolds new API Platform projects. It generates Symfony or Laravel project skeletons with optional Docker infrastructure, Next.js PWA, React-admin SPA, and AI agent instruction files. The tool configures API formats (JSON-LD, JSON:API, HAL) and documentation viewers (Swagger UI, ReDoc, Scalar). It fetches Docker files from a pinned commit of `dunglas/symfony-docker` and patches compose.yaml for CORS headers. The codebase is well-structured with clean abstractions, idempotent patching patterns, and comprehensive test coverage. It demonstrates professional PHP engineering using Symfony Console components and modern PHP features.
Connexion is a Python library and framework for building web APIs using an OpenAPI/Swagger-first approach. It consumes an OpenAPI (3.x) or Swagger (2.0) specification and automatically handles routing, request/response validation, security (API keys, OAuth2, Basic, Bearer, JWT), parameter injection, response serialization, and Swagger UI generation. The system supports both ASGI (via Starlette) and WSGI (via Flask) through a modular middleware stack, with pluggable validators, resolvers, and security handlers. It can be used as a standalone application (AsyncApp, FlaskApp) or as middleware (ConnexionMiddleware) wrapping an existing ASGI/WSGI app. The architecture is cleanly layered: middleware stack for cross-cutting concerns, operation abstraction for spec parsing, decorator chain for view function wrapping, and framework abstraction for Flask/Starlette integration. The codebase is well-structured, extensively tested, and actively maintained, making it a robust choice for spec-driven API development in Python.
Stoplight Prism is an open-source HTTP mock server and validation proxy driven by OpenAPI specifications (v2, v3, v3.1) and Postman Collections. It provides two primary CLI commands: `prism mock` to simulate an API from a schema definition, and `prism proxy` to validate requests and responses against a spec while forwarding traffic to a real upstream. The architecture is a monorepo with four packages (`core`, `http`, `http-server`, `cli`) that implement a functional pipeline: route matching, input validation (body, headers, query/path parameters, security), content negotiation, and response generation (static examples or dynamic faker-generated data). It also supports callback mocking, CORS handling, and RFC 7807 problem detail errors. The codebase is written in TypeScript with heavy use of fp-ts for composable error handling and dependency injection via reader monads. While the project is mature and well-tested (unit, integration, and a text-based harness test suite), its tight coupling to Stoplight internal packages and the steep learning curve of fp-ts reduce its overall reusability for external projects. It is not a data research repository.
pREST is a production-grade Go HTTP server that automatically exposes PostgreSQL databases as RESTful and MCP (Model Context Protocol) APIs without requiring hand-written backend code. It provides instant CRUD endpoints for any table, custom SQL template execution with parameterized queries, and a built-in Studio web UI for exploring and managing APIs. The system is architected around a hexagonal pattern with a clean adapter interface supporting multiple databases (PostgreSQL, TimescaleDB), dependency injection for controllers, and a layered middleware stack for authentication (JWT), authorization (table/field-level ACL), caching, and CORS. Security is a primary concern: SQL injection is mitigated through strict identifier validation, template parameter screening, and bound parameter binding, while credential leakage in logs is prevented by a dedicated redaction package. The codebase is well-tested with both unit tests (using sqlmock) and integration tests (against real PostgreSQL in Docker), and includes OpenTelemetry integration for observability. It is not a data research or analytics project; it is a pure application for building low-code database APIs.
PMXT is a unified prediction market SDK that aggregates data and trading across 15+ venues (Polymarket, Kalshi, Limitless, etc.) into a single, consistent interface. The system provides a core TypeScript library with a local sidecar server (Express), plus TypeScript, Python, and CLI SDKs that support both self-hosted and hosted (trade.pmxt.dev) modes. It offers market data (events, order books, trades, OHLCV), WebSocket streaming, order management (create, cancel, fetch), account balance and positions, cross-venue router for event matching and arbitrage, and data feeds (Binance, Chainlink). The architecture is a monorepo with workspaces core, sdks/typescript, sdks/python, sdks/cli, and tools. Each exchange follows a clean fetcher → normalizer → error mapper pattern, and the SDK surfaces are partially generated from the core's method signatures. While primarily an application SDK, the project includes significant data normalization, cross-venue data aggregation, and a router for analytical queries, giving it a hybrid character.
Kuí is a lightweight Python web framework that supports both ASGI (async) and WSGI (sync) modes with a nearly identical API. It provides type-safe parameter binding via typing_extensions.Annotated and Pydantic, dependency injection with caching and cleanup, automatic OpenAPI 3.1.0 documentation generation, middleware composition, class-based views for HTTP and WebSocket, background task execution, CORS support, authentication helpers (Bearer, Basic, API Key), and template rendering with Jinja2. The framework is built on baize and emphasizes developer experience through clear documentation and AI-assisted development support.
This repository contains a VS Code extension that acts as a bridge between the Antigravity IDE and a mobile device, enabling remote interaction via a local HTTPS server. The extension starts a self-signed HTTPS server on the LAN, uses the Chrome DevTools Protocol (CDP) to inspect and manipulate Antigravity IDE instances, and leverages the Language Server Protocol (LSP) to monitor and control code generation processes. A companion mobile web interface, served by the local server, provides real-time chat mirroring, message sending, file uploads, voice input, and generation control through a WebSocket connection. The architecture consists of three main parts: the VS Code extension (managing the server lifecycle and IDE integrations), the Express/WebSocket server (handling API requests, real-time communication, and static file serving), and the mobile SPA (rendering the IDE state and forwarding user interactions). Key capabilities include QR-code based pairing, end-to-end encrypted local communication, multi-instance switching, and programmatic control via an MCP server that exposes the API over stdio JSON-RPC. The extension demonstrates solid engineering practices with TypeScript, modular service layers, middleware for authentication and security, and a test suite covering core functionality. While tightly coupled to Antigravity's UI and protocols by necessity, it isolates concerns through well-defined services (CDP, LSP, antigravity interactions) and reusable patterns such as the CSP middleware, CDP wrapper, and stdio JSON-RPC proxy. Ongoing maintenance addresses selector fragility and API updates, ensuring compatibility with evolving IDE and VS Code versions.
XXL-JOB is a distributed task scheduling framework designed for rapid development, simplicity, and lightweight operation. It consists of a scheduler center (admin) and multiple executors. The admin provides a web UI for CRUD job management, scheduling (cron, fix rate, fix delay), routing strategies (first, last, round, random, consistent hash, LFU, LRU, failover, busyover, sharding broadcast), misfire handling, alarm (email), and monitoring. Executors run on any JVM and communicate with the admin via Netty-based HTTP RPC. The framework supports BEAN (annotated methods), GLUE (online Groovy/script editing), script tasks (Shell, Python, PHP, NodeJS, PowerShell), HTTP tasks, and AI tasks (Ollama, Dify, OpenClaw). It includes an OpenAPI for cross-language integration, user management with role-based permissions, and Docker deployment. The architecture is modular: xxl-job-core provides the executor runtime and shared interfaces, xxl-job-admin is the Spring Boot admin application, and sample executors demonstrate integration. External dependencies include MySQL (persistence), Netty (executor server), Groovy (glue tasks), and Spring Boot. The framework is production-ready with HA support for both scheduler and executor clusters.
Apollo is a distributed configuration management system designed for microservices architectures. It provides a centralized web portal (AngularJS frontend with Spring Boot backend) for managing application configurations across multiple environments (DEV, FAT, UAT, PRO, etc.) and clusters. The system supports real-time configuration updates via long-polling, version management, grayscale (canary) releases, role-based access control, and comprehensive audit logging. It exposes REST APIs for programmatic management through an OpenAPI v1 layer and provides client SDKs for various languages. The architecture consists of three main services: apollo-portal (management UI and OpenAPI endpoints), apollo-adminservice (admin CRUD operations), and apollo-configservice (client-facing configuration delivery with long-polling notifications). These services share a common business logic module (apollo-biz) and persist data in MySQL databases (ApolloConfigDB and ApolloPortalDB). The portal communicates with admin services via REST, while clients poll the config service for updates. The system also includes a service registry module for discovery of admin service instances, supporting multiple discovery mechanisms (Eureka, Consul, Nacos, Zookeeper, database, Kubernetes). Key entry points include the portal web UI, OpenAPI v1 endpoints (/openapi/v1/), admin service REST APIs, and config service APIs for client configuration retrieval and notification. The primary data flow involves creating/modifying configurations through the portal or OpenAPI, which are stored in the database. Changes trigger release messages that are scanned by the config service to notify connected clients. Clients then fetch the latest configurations via the config service. The system also supports gray releases, branching, rollback, and configuration import/export. External dependencies include MySQL (primary database), optional service discovery mechanisms (Eureka, Consul, Nacos, Zookeeper, Kubernetes), LDAP/OIDC for authentication, and email/MQ services for notifications. The codebase is modular with clear separation of concerns, extensive test coverage, and a well-defined SPI (Service Provider Interface) pattern for extensibility.
mitmproxy2swagger is a CLI tool that automatically converts HTTP traffic captures from mitmproxy or browser HAR exports into OpenAPI 3.0 specifications. It enables reverse-engineering REST APIs by analyzing recorded traffic without manual inspection. The tool uses a two-pass workflow: the first pass identifies API paths and generates a template file with parameter placeholders; after the user edits the template to select endpoints, the second pass produces full endpoint descriptions with inferred request/response schemas. Architecturally, the tool is a single-purpose Python application organized into modular components: input readers (mitmproxy_capture_reader.py for binary flow files, har_capture_reader.py for HAR JSON), a core orchestration module (mitmproxy2swagger.py) that handles argument parsing, format auto-detection, and schema merging, and utility modules (swagger_util.py for OpenAPI schema generation, console_util.py for progress display). The tool supports multiple content types (JSON, msgpack, form-urlencoded) and can optionally include example data and headers in the output. Key entry points are the `mitmproxy2swagger` command with arguments for input file, output path, API prefix, and optional flags. External dependencies include mitmproxy for reading flow files, ruamel.yaml for YAML output, json-stream for streaming HAR parsing, and msgpack for msgpack support. The codebase is well-maintained with CI/CD, tests, Docker support, and pre-commit hooks.
AutoRest is a mature, plugin-based code generation tool that transforms OpenAPI (Swagger) specifications into client SDKs for multiple languages (C#, Java, Python, Ruby, Go, Node.js, TypeSpec). The system operates as a pipeline: it loads OpenAPI documents, converts Swagger 2.0 to OpenAPI 3.0, validates schemas and semantics, applies user-defined transformations (directives), deduplicates components, and then feeds the resulting code model into language-specific emitters. The core engine is written in TypeScript and runs as a CLI tool (`autorest`), but also exposes a programmatic API for embedding. Configuration is handled via literate markdown/YAML files with conditional guards and extension loading. Architecturally, AutoRest is a monorepo with over 50 packages organized into apps, extensions, libs, and tools. The pipeline is built dynamically from configuration, using a directed acyclic graph of plugins that communicate through a shared data store with source mapping. Key entry points include the CLI (`packages/apps/autorest/src/app.ts`), the core orchestrator (`packages/extensions/core/src/lib/autorest-core.ts`), and the modelerfour extension that produces the intermediate code model. External dependencies include npm packages for YAML/JSON parsing, AJV for schema validation, and system-level tools (dotnet, java, python) for running language-specific generators. Data flows begin with OpenAPI files loaded into a virtual file system (DataStore), then pass through stages: identity normalization, schema validation, semantic validation, profile filtering, tree-shaking, OAI2-to-OAI3 conversion, modelerfour processing (flattening, renaming, deduplication), and finally emission to TypeSpec or other target languages. The system supports both ARM (Azure Resource Manager) and data-plane APIs, with special handling for pagination, polymorphic models, and Azure-specific extensions. Despite its planned retirement (July 2026) in favor of TypeSpec-first tooling, AutoRest remains actively maintained with recent commits and a large test suite. The codebase demonstrates strong engineering practices in areas like source-map tracking, configuration merging, and plugin isolation, though it carries some technical debt from years of evolution (e.g., heavy use of `any` types, duplicated deduplication logic, and legacy compatibility layers).
OpenAPI Generator CLI is a Node.js/TypeScript command-line wrapper around the Java-based OpenAPITools/openapi-generator JAR. Despite using NestJS, it is not a server: NestJS provides a DI application context that wires a Commander CLI. On every invocation (main.ts → AppModule.onApplicationBootstrap), it reads openapitools.json, resolves a generator version (querying Sonatype's Solr search for the latest stable when unset), writes it back to config, downloads and caches the JAR — atomically, via temp file + rename — then asks the Java CLI itself (via `help` and `completion` output) what commands it exposes, registers them dynamically, and spawns `java -jar ... <command>` with inherited stdio. It supports HTTP(S) proxies, JAVA_OPTS, custom generator JARs (classpath merge), and a Docker execution mode. Beyond pass-through, the CLI adds value the raw Java tool lacks: a `version-manager` subcommand (list/set/remove tagged versions backed by an interactive table picker) and a config-driven batch generator in openapitools.json where named generators map glob patterns to invocations with placeholder tokens (#{name}, #{cwd}, #{relPath}, #{ext}, ...), executed concurrently (max 10 processes). The repo is an Nx single-app monorepo bundled into a shebang'd main.js and released via semantic-release; GitHub Actions CI runs lint, unit tests, and real Java-based E2E on Ubuntu and macOS. Unit test coverage is thorough across config, version management, command pass-through, and command construction. Genuinely clever parts: dynamic discovery of an external CLI's command surface, atomic binary caching, and a table-to-interactive-select UI. The warts: a ~100-entry hardcoded fallback version list embedded in source, a legacy root lib/index.js publishing script superseded by the webpack package plugin, leftover NestJS scaffolding (environment stubs, 'not a production server' comment), deprecated RxJS toPromise() usage, an ESLint root config that effectively ignores all files, and a Nix flake pinned to Node 18 while the package requires Node 22. It does what it claims and is actively maintained, but the residue keeps it from being exemplary.
This repository is a modern, lightweight full-stack application template built with Turborepo. It consists of two main apps: a React single-page application (Vite + TanStack Router/Query/Form) for the frontend, and a Hono (Node.js) server providing an oRPC-based API with OpenAPI (Scalar) documentation. Authentication is handled by better-auth (email/password) with PostgreSQL via Drizzle ORM. The system supports CRUD operations for posts, includes dark/light theme toggling, and is fully containerized with Docker. The architecture follows a modular monorepo structure with shared packages for API contracts (oRPC), authentication, database schema and client, UI components (shadcn/ui), and reusable tooling configurations (ESLint, Prettier, Tailwind CSS, TypeScript). The codebase demonstrates strong engineering practices: environment variable validation with valibot, type-safe API contracts with oRPC, session-based auth with CORS, and a robust monorepo setup with Turborepo caching and dependency management.
This repository is a CLI tool and Python library that generates modern, typed Python HTTP client libraries from OpenAPI 3.0 and 3.1 specifications. The system parses an OpenAPI document (YAML or JSON), validates it against Pydantic models of the OpenAPI schema, and then converts the parsed structure into an internal representation of endpoints, models, and properties. Using Jinja2 templates, it generates a complete Python package with attrs-based model classes, httpx-based sync/async endpoint functions, a Client class with authentication support, and packaging metadata (Poetry, PDM, uv, or setup.py). The generated code is fully typed and includes serialization/deserialization methods, error handling, and support for complex OpenAPI features like allOf, oneOf, discriminated unions, enums, circular references, and custom content types. The architecture is a monolithic Python package with clear separation of concerns: a CLI entry point (typer), a configuration system (YAML/JSON config files with class overrides), a parser module that converts OpenAPI schemas into a property type hierarchy (StringProperty, IntProperty, UnionProperty, ModelProperty, etc.), and a template rendering engine. The parser uses a protocol-based design for property types, making it extensible. The system also includes a vendored copy of the openapi-schema-pydantic library for schema validation. Security is a key concern, with features like UntrustedString to prevent code injection in generated output and fuzz testing that generates random OpenAPI documents with dangerous strings. The project has extensive testing: unit tests for all parser components, end-to-end snapshot tests using golden records, functional tests that execute the generated code, integration tests against a live test server, and property-based fuzz testing. The generated client libraries are production-ready, using modern Python features like `from __future__ import annotations`, `|` union syntax, StrEnum/IntEnum, and the UNSET sentinel for optional fields. The tool is configurable via CLI flags and config files, supporting custom templates, post-generation hooks, and various packaging backends.
This is a NestJS boilerplate for building RESTful APIs with TypeScript, PostgreSQL, TypeORM, and modern DevOps practices. The system provides a modular backend architecture with authentication (JWT), user management, post management, email verification via BullMQ queues, health checks, Swagger API documentation, and comprehensive testing setup. It follows NestJS best practices with clear separation of concerns across modules for auth, users, posts, health, and background jobs. Key features include cursor-based and offset-based pagination, internationalization (i18n), Redis caching, security headers via Helmet, and environment-based configuration management. The codebase demonstrates strong engineering practices with reusable utilities for password handling, configuration validation, and sophisticated cursor pagination that could be extracted to other projects with minimal modification.
The Taxi repository implements a comprehensive language workbench for the Taxi DSL (Domain Specific Language) used to define data models, service contracts, and API interfaces with semantic meaning. It features a polyglot architecture with JVM-based compiler, type system, and language server, alongside TypeScript/JavaScript client tools and documentation. The system provides code generation for multiple targets (Java, Kotlin, TypeScript, OpenAPI, Protobuf, etc.), IDE integration via LSP, a CLI for project management, and a query language (TaxiQL). Key strengths include a sophisticated structural type system, expression compilation with intelligent caching and error handling, reactive LSP architecture preventing excessive recompilation, and a clean plugin system for extensibility.
This repository is the central specification and test suite hub for the RealWorld project (a Medium.com clone demo app). It does not contain any runnable application code. Instead, it defines the API contract via an OpenAPI spec (specs/api/openapi.yml), provides comprehensive test suites in Hurl and Bruno formats for backend validation, and a shared Playwright E2E test suite for frontend validation. It also includes a shared CSS theme (assets/theme/styles.css), documentation built with Astro/Starlight (docs/), and SVG logo generation scripts. The repository serves as the single source of truth that all RealWorld implementations (over 100 backends and frontends) must conform to. Its architecture is that of a specification and validation toolkit, not a deployable service. Key entry points are the Makefile for running tests and generating Bruno collections, and the test runner scripts in specs/api/. External dependencies include Hurl, Bruno, Playwright, Bun, and Astro.
Zodios is a TypeScript library that provides a fully typed and validated REST API client built on top of axios and zod, along with a companion server adapter for Express. The core library (`@zodios/core`) offers a centralized API definition format using zod schemas, auto-complete for paths and parameters on the client side, and runtime validation of both request parameters and responses. It includes a sophisticated plugin system for intercepting requests and responses with support for named plugin replacement and per-endpoint registration. The library also provides helper functions for building API definitions (`makeApi`, `apiBuilder`, `parametersBuilder`, `makeCrudApi`, `mergeApis`) and internal plugins for form-data, form-url, and text request formats. The system is designed for end-to-end type safety, allowing developers to share API definitions between client and server code. It has been well-architected with a clean separation of concerns: the client class (`Zodios`) handles HTTP communication through axios and delegates schema validation to the validation plugin, while the API definition helpers provide a builder pattern for composing endpoints. The plugin system is particularly notable for its flexible registration (global, by alias, or by method+path) and its correct reverse-order execution for response interceptors. Overall, the codebase demonstrates strong TypeScript craftsmanship, disciplined use of type inference and utility types (e.g., path parameter extraction at the type level), and a modular design that allows features like CRUD generation and API merging. While not revolutionary, it is a solid, production-quality library that effectively solves the problem of type-safe REST communication.