Paperclip is a Rust toolkit for working with OpenAPI specifications. It provides code generation for type-safe HTTP clients and servers from OpenAPI v2/v3 specs, procedural macros to derive OpenAPI annotations from Rust code, and an Actix-web plugin for serving generated specs and integrating with handlers. The architecture is modular with separate crates for core types, macros, Actix integration, and CLI tools. Key features include reference resolution with cycle detection, emitter-based code generation strategy, builder patterns with compile-time field validation, and macro-driven spec generation. The project is actively maintained with recent commits, CI workflows, and frequent version updates.
FoalTS is a full-featured Node.js/TypeScript web framework structured as a monorepo with modular packages (core, CLI, JWT, TypeORM, GraphQL, storage, social auth, etc.). The framework provides declarative routing via decorators, a hook system for middleware/validation/authorization, dependency injection, and built-in support for OpenAPI, GraphQL, WebSockets, and file storage. Under the hood it uses Express, AJV, and TypeORM, with session stores for Redis, MongoDB, and SQL databases. The CLI generates projects, controllers, entities, and REST APIs, and includes upgrade commands across major versions. The codebase demonstrates solid engineering: thorough unit/e2e tests (over 2100 tests), documentation-as-tests, and a consistent pattern of abstract services (Store, Disk, Logger) resolved via configuration. Key reusable patterns include the hook/decorator system for validation and authentication, the abstract OAuth2 provider base class, and the CLI generator template engine. However, some deprecations (e.g., hashPassword→PasswordService) and outdated Docker images in development config indicate moderate technical drift. The project is actively maintained with frequent releases, daily CI on Node 22/24, and a well-documented upgrade path.
AutoRest is a production-grade code generation tool that transforms OpenAPI (Swagger) specifications into client SDKs for multiple programming languages, including C#, Java, Python, Ruby, Go, and Node.js. It is the primary tool used by Azure to generate SDKs for Azure services, but it can be used for any REST API. The system ingests OpenAPI 2.0/3.0 documents, validates them, and processes them through a plugin-based pipeline to produce language-specific client libraries. The architecture is built around a directed acyclic graph of pipeline plugins, each responsible for a specific transformation stage (modeling, flattening, naming, emitting). The core engine orchestrates the pipeline, manages configuration loading and merging, and handles extension lifecycle. A virtual file system with source mapping tracks the provenance of generated code back to original spec positions, enabling accurate error reporting and blame tracking. Key entry points include the CLI application at packages/apps/autorest/src/app.ts, the core processing engine at packages/extensions/core/src/lib/autorest-core.ts, and the modelerfour extension that converts OpenAPI to an intermediate code model. The system also includes an experimental path to convert OpenAPI to TypeSpec via the openapi-to-typespec extension. External dependencies include npm for extension management and runtime environments (Java, Python, .NET) for generated code validation. The data flow begins with loading and parsing OpenAPI specs, followed by validation, conversion to a language-agnostic code model, and finally emission of language-specific SDK code. The pipeline supports caching, configuration merging with interpolation, and directive-based customization (e.g., removing operations, renaming components). The codebase is a large monorepo with many interdependent packages, showing signs of long-term evolution and some technical debt.
AutoFilterer is a .NET library that automatically generates LINQ expressions from Data Transfer Objects (DTOs) for filtering, sorting, and pagination on IQueryable collections. It is designed to be compatible with OpenAPI 3.0 specifications, unlike oData or GraphQL. The core architecture revolves around filter DTOs that inherit from FilterBase or its derivatives (PaginationFilterBase, OrderableFilterBase). Properties in these DTOs are decorated with attributes (e.g., StringFilterOptions, OperatorComparison, CompareTo) or use special types (StringFilter, OperatorFilter<T>, Range<T>) to define filtering rules. The library builds expression trees at runtime and applies them via the ApplyFilter extension method. It also provides a Swagger integration package (AutoFilterer.Swagger) to expose filter parameters in Swagger UI, and a source generator (AutoFilterer.Generators) to automatically create filter DTOs from entity classes. The codebase is well-structured with clear separation of concerns: abstractions (IFilter, IFilterableType), attributes, types, extensions, and a dynamic filter variant. It includes comprehensive unit tests, benchmark tests, and a sandbox application demonstrating usage with a Northwind database. The library targets netstandard2.0, netstandard2.1, and net9.0, making it broadly compatible. While the core library is mature and actively maintained, some ancillary packages (e.g., Swagger integration) use slightly outdated dependencies (Swashbuckle 5.x), and the documentation has some TODO sections. Overall, it is a solid, reusable filtering framework with high craftsmanship in expression tree manipulation.
This is the swagger-codegen-generators repository, a Java library that provides code generation for client and server stubs from OpenAPI (formerly Swagger) specifications. It is not a standalone application but a library consumed by the swagger-codegen v3 tool (or used programmatically). The codebase implements a template-driven architecture where language-specific generators extend abstract base classes (e.g., AbstractJavaCodegen, AbstractTypeScriptClientCodegen) and use Handlebars/Mustache templates to produce output. It supports a wide range of languages including Java, C#, Go, Python, Ruby, Swift, TypeScript, Kotlin, Dart, PHP, Scala, R, and Node.js, with frameworks like Spring, JAX-RS, Micronaut, Vert.x, ASP.NET Core, and more. Key file patterns include feature interfaces for composable generator capabilities (e.g., BeanValidationFeatures, GzipFeatures), Handlebars helper lambdas for template logic, and schema handlers for composed schemas (allOf/oneOf/anyOf). The project has extensive test coverage with unit and integration tests for model and API generation. While the core architecture is solid, the base class DefaultCodegenConfig is monolithic and the hundreds of template files pose maintenance drift risks. The project is actively maintained with CI workflows, issue templates, and recent commits.
This is a Homebridge plugin (`@switchbot/homebridge-switchbot`) that bridges SwitchBot IoT devices (lights, curtains, locks, sensors, vacuums, etc.) into Apple HomeKit using both HAP and Matter protocols. It communicates via Bluetooth Low Energy (BLE) and the SwitchBot OpenAPI cloud API, with configurable fallback and rate-limiting. The plugin provides a rich configuration UI served through Homebridge Config UI X, including device discovery, credential management, and advanced polling settings. The architecture follows a platform plugin pattern with two platform classes (HAP and Matter), a resilient client layer (debounce, circuit breaker, daily budget tracking), a device factory and abstract base class for device-specific implementations, and extensive Matter cluster mappings. While the codebase is well-structured and actively maintained, it suffers from a large monolithic platform file (~2800 lines), low test coverage (~1.36%), and a dependency conflict requiring `--legacy-peer-deps` during installation. ESLint configuration also fails in CI. Nonetheless, the plugin is feature-rich, handles edge cases like BLE encryption and OpenAPI rate limits, and includes a polished custom UI.
Knife4j is an enhanced Swagger/OpenAPI user interface and aggregation toolkit for the Java Spring ecosystem. In production it deploys as a set of Spring Boot auto-configuration starters: openapi2 (springfox), openapi3 (springdoc), aggregation from disk/cloud/Nacos/Eureka/Polaris sources, and Spring Cloud Gateway discovery, plus an optional standalone `knife4j-insight` server and multiple frontend UIs (Vue 2, Vue 3, React/Ant Design Pro). The core data flow is: a Spring Boot service exposes OpenAPI JSON via springdoc/springfox; Knife4j customizers and plugins enrich that JSON with API ordering, markdown docs, global parameters, and enhanced metadata; the frontend consumes the OpenAPI document and renders API lists, debug consoles, OAuth2 flows, and offline export pages. Aggregation starters fetch and merge specs from remote registries or local files, cache them in memory, and proxy or route requests to upstream services.
Integuru is a Python application that reverse-engineers API requests from browser traffic to generate runnable integration code. It takes a HAR file (HTTP archive) containing browser network requests and cookie data, then uses LLMs to analyze these requests to identify which endpoint performs a user-specified action. The system builds a dependency graph to determine what prerequisite requests are needed to gather dynamic parameters (like IDs, tokens), and finally generates Python code that can reproduce the action by making the necessary HTTP requests in the correct order. The architecture uses LangGraph for workflow orchestration, with specialized LLM-powered agents handling different aspects of the analysis (URL identification, dynamic parameter extraction, dependency resolution).
This is a TypeScript library providing a builder API for typesafe Next.js server actions with Zod validation. It is structured as a monorepo with core package `zsa`, React hooks (`zsa-react`), React Query integration (`zsa-react-query`), and OpenAPI exposure (`zsa-openapi`). The core library supports input validation (JSON, FormData, useActionState), procedures for middleware chaining with context propagation, typed error handling via `ZSAError`, configurable retries and timeouts, and client-side hooks (`useServerAction`, `useActionState`). The OpenAPI module generates REST endpoints and OpenAPI specifications from server actions. The codebase is well-organized with fluent builder patterns, comprehensive test coverage (Jest + Playwright), and a documentation site using Fumadocs. However, it is a personal project currently lacking support for Next.js 15, and all packages are pre-1.0 (0.x), indicating potential instability and limited maintenance commitment.
UtilMeta is a progressive Python meta-framework for building declarative APIs with integrated ORM, authentication, caching, client generation, and operations monitoring. The codebase provides a modular architecture with backend adaptors for Django, Flask, FastAPI, Sanic, Tornado, and Starlette, allowing developers to write framework-agnostic API services. Core features include declarative API classes with route mounting, request parameter extraction via decorators, automatic OpenAPI spec generation, a plugin system for cross-cutting concerns (CORS, caching, rate limiting), and a full ORM layer that compiles queries to Django/SQLAlchemy/Peewee backends. The ops module offers built-in service monitoring, logging, alerting, and supervisor connectivity for production management. Key entry points are the UtilMeta service class, the API base class, the CLI tool (meta), and the operations configuration. External dependencies include Django, databases libraries, jwcrypto, psutil, and utype for type validation.