ewebsock is a Rust WebSocket client library designed to compile and run both natively and on the web via WASM. It provides a simple, uniform API (`connect`, `ws_connect`, `ws_receive`) that abstracts away platform differences: on native it uses `tungstenite` with either a dedicated thread (default) or an opt-in `tokio` backend, while on web it wraps the browser `WebSocket` API via `web-sys`/`wasm-bindgen`. The library handles binary and text messages, ping/pong, connection lifecycle events, and supports TLS (rustls) and custom headers/subprotocols. It is small, well-documented, and heavily feature-flagged to keep dependencies minimal, making it suitable for GUI apps (e.g., egui) that need real-time communication across desktop and browser targets. The codebase is clean and exhibits strong craftsmanship: the separation of backends is clean, error handling is thorough (including read timeouts and graceful shutdown), and the web implementation carefully manages Blob/ArrayBuffer conversion and memory-safe closure lifetimes. The repository also includes an example egui app and an echo server for testing. While it is primarily a library, it is also an application in the sense that it ships executable examples. Overall, it is a mature, well-maintained crate with a clear API and robust platform abstraction.
CCXT is a cryptocurrency exchange trading library that provides a unified API for over 100 exchanges across 7 programming languages (TypeScript/JavaScript, Python, PHP, C#, Go, Java). The core is written in TypeScript from which all other language bindings are transpiled. It implements both REST and WebSocket APIs for market data, trading, and account management. The library normalizes exchange-specific data formats into a common schema, enabling cross-exchange arbitrage and analytics. Key architectural patterns include a base Exchange class with exchange-specific subclasses, a pro/ subdirectory for WebSocket-enabled exchanges, static_dependencies/ for vendored third-party code (ethers, starknet, bip39, etc.), and an extensive test suite with both static and live tests. The repository includes a playground (Next.js web IDE), CLI tool, documentation site (Fumadocs), CI/CD for all languages, and Docker development environment.
Iris is a mature, full-featured Go web framework providing a comprehensive set of tools for building web applications and APIs. The core is a monolithic HTTP framework with a trie-based router, middleware pipelines, MVC pattern support, dependency injection via the 'hero' package, websocket integration, session management, caching, i18n, and a rich set of built-in middleware. The codebase is organized into clear packages (context, router, mvc, sessions, middleware, view, etc.) and includes hundreds of examples demonstrating common patterns. While the framework is heavily reflection-based in some areas (dependency injection, MVC activation), the architecture is well-structured and the components are generally reusable. The project shows active development (though some examples use deprecated go-bindata) and maintains a healthy release cycle.
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.
ClawDeckX is a desktop/web application that provides a management interface for the OpenClaw AI gateway. It enables users to configure and manage AI agent collaborations, monitor system metrics, install extensions, and access a template marketplace for agent configurations. The application features a Go backend with REST API and WebSocket endpoints, a React/TypeScript frontend, and uses SQLite/PostgreSQL for data storage. Key capabilities include real-time agent room collaboration, configuration management, multi-agent workflow orchestration, notification systems, and cross-platform deployment options.
This is a monorepo of first-party middleware and service implementations for the Fiber web framework (v3). It provides production-grade authentication (JWT, PASETO, SPNEGO/Kerberos), authorization (Casbin, OPA), observability (OpenTelemetry, Prometheus, New Relic, Sentry, custom monitor/uptime dashboards), real-time communication (WebSocket, Socket.IO v5), Web Application Firewall (Coraza), resilience patterns (circuit breaker, CPU load shedding), structured logging (zap, zerolog), internationalization, hCaptcha verification, Swagger UI/OpenAPI docs, profiling (fgprof), and Testcontainers integration for testing. Each package lives in its own Go module under v3/, following a consistent Config+New() pattern and includes extensive test coverage with benchmarks. The architecture is library-oriented: components are imported by Fiber applications, not run standalone. The codebase demonstrates strong engineering practices: config validation at construction, atomic concurrency patterns, lock-free read paths, and protocol-level optimizations (e.g., zero-copy Socket.IO codec, WebSocket write coalescing). Some packages show signs of technical drift (e.g., paseto uses a deprecated library, socketio has mutable package globals), but overall the repository is actively maintained with weekly releases and automated dependency updates.
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.
This is a Go client library for the Slack API, providing comprehensive coverage of Slack's REST API, Real-Time Messaging (RTM) over WebSocket, Socket Mode for event-driven interactions, and the Block Kit for rich interactive messages. It enables developers to build Slack apps, bots, and integrations with full access to Slack's platform features including messaging, files, admin functions, workflows, and more. The library is organized into several packages: `slack` (main client with all API methods), `socketmode` (WebSocket client for Socket Mode), `slackevents` (Events API parsing), `slacktest` (mock server for testing), and `internal` (backoff, error handling). It uses a functional options pattern for API calls, context propagation for cancellation, and a pluggable retry system. The Block Kit is implemented with builder patterns and custom JSON serialization for type-safe block construction. Key entry points include `slack.New(token)` to create a client, `socketmode.NewClient` for WebSocket connections, and `slackevents.ParseEvent` for Events API payloads. The library handles authentication, rate limiting, pagination, and error responses. External dependencies are minimal, relying primarily on the Go standard library and a WebSocket library for real-time communication.
Pelican Wings is a production-grade game server management daemon (agent) built in Go. It serves as the control plane for the Pelican Panel, managing Docker containers that run game servers. The daemon exposes a comprehensive HTTP API for server lifecycle operations (start, stop, install, backup, transfer), real-time WebSocket streams for console output and server stats, and a built-in SFTP server for file management. It communicates with a remote Panel API to synchronize server configurations, validate user credentials, and report activity logs. The codebase demonstrates strong systems engineering with a focus on security (sandboxed filesystem using openat2 syscalls, token authentication, download IP filtering), performance (disk-space caching, atomic generics), and reliability (crash detection, state persistence, cron-based backups). It supports multiple backup backends (local disk, S3), parallel server bootstrapping, and self-update via GitHub releases. The architecture follows a modular pattern with clear separation between API routing, server management, filesystem operations, and integration adapters. While the code is a fork of Pterodactyl Wings with some incomplete rebranding, it remains actively developed and production-ready.
Artillery is a cloud-scale load testing and functional testing framework for backend services and APIs. It supports multiple protocols (HTTP, WebSocket, Socket.IO, Playwright, PostHog) through a plugin-based engine architecture. The system is primarily a CLI tool (built on oclif) that executes YAML/JSON test scripts defining virtual user flows with configurable arrival phases, payloads, and assertions. It provides distributed execution across local worker threads, AWS Lambda, AWS ECS/Fargate, and Azure ACI, with a bill-of-materials (BOM) system that bundles test dependencies for cloud workers. Metrics are aggregated via a custom Simple Statistics Measurement System (SSMS) supporting counters, histograms (DDSketch), and rates, and can be published to Datadog, CloudWatch, Prometheus, OpenTelemetry, Splunk, New Relic, and other observability platforms. The codebase is a monorepo managed with Turborepo, containing the core runner, platform integrations, first-party plugins (expect, ensure, apdex, slack, fake-data, metrics-by-endpoint, publish-metrics, memory-inspector), and shared type definitions. Key entry points include the `artillery` binary (`packages/artillery/bin/run`), the core runner (`packages/artillery/lib/core/runner.ts`), and platform launchers (`packages/artillery/lib/launch-platform.ts`). External dependencies include AWS SDK, Azure SDK, Playwright, got (HTTP client), and various metric publishing SDKs. The architecture is event-driven, using EventEmitter for lifecycle events and plugin hooks, with a global `global.artillery` object for shared state.
This is a Nuxt 3 module that integrates Apollo GraphQL client into Nuxt applications. It provides a flexible configuration system for defining multiple Apollo clients with HTTP and WebSocket endpoints, authentication token management, and SSR support. The module auto-imports composables like useAsyncQuery, useQuery, useMutation, and useSubscription, and provides hooks for custom authentication and error handling. It also supports hot module replacement for Apollo client configuration files. The architecture uses Nuxt's module system (defineNuxtModule) to hook into the build process. It reads client configurations from nuxt.config or external files, generates runtime templates, and sets up a Nuxt plugin that creates ApolloClient instances with appropriate links (HTTP, WebSocket, auth, error). The composables layer provides SSR-friendly async query wrappers and authentication helpers. WebSocket support includes a restartable client for reconnection. Key entry points are src/module.ts (module setup), src/runtime/plugin.ts (client creation and plugin), and src/runtime/composables.ts (user-facing composables). External dependencies include @apollo/client, @vue/apollo-composable, graphql-ws, and @nuxt/kit.
SocketIOClient-Unreal is a Socket.IO client plugin for Unreal Engine that enables real-time bidirectional communication between Unreal applications and Socket.IO servers. The plugin features a modular architecture with separate modules for core client functionality (SocketIOClient), low-level Socket.IO implementation (SocketIOLib), JSON handling (SIOJson), and utility functions (CoreUtility). It provides both Blueprint-accessible components (USocketIOClientComponent) and native C++ interfaces (FSocketIONative) for flexible integration. The plugin handles connection management, event emission/reception, namespaces, rooms, and includes sophisticated JSON-UStruct conversion utilities with Blueprint compatibility.
xyOps is a self-hosted, multi-server job scheduler and monitoring platform written in Node.js (CommonJS) with a browser-based single-page application. It is the successor to Cronicle and provides cron-like event scheduling, distributed job execution via WebSocket satellite agents, visual workflow orchestration, real-time server monitoring, alerting, ticketing, secrets management, and a plugin marketplace. The backend is organized around a central engine class (`lib/engine.js`) that mixes in modules for scheduling, job lifecycle, monitoring, alerts, maintenance, SSO, and API handling; the frontend uses a custom page framework with jQuery, CodeMirror, and WebSocket-driven live updates. In production, events are defined with triggers (schedule, interval, single, catchup, range, blackout), jobs are launched locally or on remote satellites, and job output is streamed via SSE/WebSocket. Monitoring data (CPU, memory, disk, processes) flows from satellites to the master, where JEXL expressions evaluate alert conditions and store multi-resolution timelines. The system persists to SQLite/Postgres/Redis via a custom storage abstraction (unbase) and supports import/export, snapshots, activity logging, and a plugin marketplace. Maintenance is active: frequent releases, CI workflows, security patching, and a comprehensive integration test suite are present. The codebase shows some technical debt—large monolithic files, duplicated CRUD patterns, callback-heavy async, and a custom UI framework—but the core architecture is modular, well-documented, and backed by a real test suite.
Moco is a Java library and standalone server for creating mock HTTP servers, primarily used for integration testing. It supports HTTP/HTTPS, REST, WebSocket, SSE, CORS, proxy with failover/playback, recording/replaying, and template-based responses. Architecture is modular: moco-core provides interfaces and implementations (Netty-based server, request matchers, response handlers), moco-runner adds a CLI for JSON-based configuration and standalone execution, and moco-junit/moco-junit5 provide JUnit integration. The system is configured either via a fluent Java API (central `Moco` static factory) or JSON configuration files, making it easy to stub endpoints in tests or as a standalone mock service. It uses Netty for high-performance HTTP serving, Jackson for JSON processing, Freemarker for templates, and Guava for utilities. The codebase is well-structured with clear separation of concerns, extensive tests, and support for modern protocols like HTTP/2 and WebSocket.
Mochiweb is a lightweight, battle-tested HTTP server library written in Erlang. It provides a full HTTP/1.1 server with support for chunked transfer encoding, compression (gzip, zstd), WebSocket upgrades, and multipart form parsing. The library is designed as a collection of composable, parameterized modules, with a core socket server (`mochiweb_socket_server`) that manages an acceptor pool and delegates request handling to user-provided callback modules. This architecture has made Mochiweb the foundation for numerous Erlang web frameworks, including Nitrogen, Chicago Boss, and Webmachine. Key entry points include `mochiweb_http:start/1` for starting a plain HTTP listener and `mochiweb_socket_server:start/3` for custom socket servers. Request handling flows through `mochiweb_request` (parsing, body streaming, file serving) and `mochiweb_response` (header encoding, streaming, compression). The library also ships with standalone utilities: `mochijson2` for JSON encoding/decoding, `mochiweb_html` for loose HTML tokenization, `mochiweb_util` for URL/header parsing, and `mochiweb_headers` for case-insensitive header dictionaries. While the core is production-grade and actively maintained, some internal modules use deprecated OTP APIs (e.g., `httpd_util:rfc1123_date/0`, `{ssl_imp, new}`) and the state format in `mochiweb_socket_server` includes backward-compatibility shims. The example projects and test suite are comprehensive, covering edge cases from RFC 7230 and WebSocket protocols. Overall, Mochiweb remains a solid choice for embedding an HTTP server in Erlang applications, with several components (especially `mochijson2` and `mochiweb_util`) that are widely reused in isolation.
Iodine is a high-performance concurrent web server for Ruby applications, built as a wrapper around the C-based facil.io framework. It provides native HTTP/WebSocket/Server-Sent Events support, Rack compliance for serving Ruby web applications, and a built-in Pub/Sub system with optional Redis scaling for horizontal distribution. The architecture follows a master-worker model using multiple processes and threads to handle thousands of concurrent connections, with critical networking components implemented in C for performance and Ruby bindings for developer productivity. Key features include static file serving with gzip and X-Sendfile support, a secure Mustache template engine with automatic HTML escaping, a fast JSON parser claiming 20-90% speed improvements over Ruby's standard library, and TLS support (though marked as having known issues for production use). The server integrates with Rack applications through a custom handler and provides upgrade hooks for WebSocket/SSE protocols via the Rack environment. Pub/Sub functionality uses an engine pattern allowing swap between internal cluster-based and external Redis backends. Entry points include the `exe/iodine` CLI executable and programmatic controls via `Iodine.listen`, `Iodine.start`, and `Iodine.stop`. Data flows involve HTTP requests parsed by the C-based HTTP processor, routed to Rack applications or static file handlers, with WebSocket connections upgraded via Rack's `env['rack.upgrade?']` mechanism. The Pub/Sub system operates independently for real-time messaging across processes or machines. External dependencies include the vendored facil.io C library, OpenSSL development headers for TLS support, and optionally the Redis gem for clustered Pub/Sub.
Tunet is a modern, responsive React dashboard for Home Assistant that provides a customizable interface for monitoring and controlling smart home entities. The application features a React/Vite frontend with an Express/Node.js backend, using SQLite for persistent storage of user configurations. It implements a modular card-based UI system with 20+ specialized card types (lights, climate, media, etc.), real-time WebSocket synchronization with Home Assistant, and extensive customization options including theming, layout configuration, and plugin-like extensibility. The application follows React best practices with custom hooks, context API for state management, and a well-organized component architecture.
JSPrintManager is a client-side printing and scanning solution enabling web applications to bypass browser print dialogs by communicating with a native client application via WebSocket. The system consists of a core JavaScript library (JSPrintManager.js) that provides APIs for creating print/scan jobs, managing printer connections, and handling device-specific communication protocols (serial, USB, Bluetooth, TCP/IP, HID, IPP). A React-based demo application showcases features including printing various file formats (PDF, images, Office documents), raw printer command languages (ZPL, ESC/POS), bidirectional device communication, printer monitoring, and scanning functionality. The solution requires installation of a lightweight native client on user machines to establish the WebSocket bridge between browser and hardware devices.
Reload is a Node.js library and CLI tool that automatically refreshes web pages in the browser when server-side code changes. It works by injecting a client-side JavaScript file that opens a WebSocket connection to the server. When the server restarts (or a manual reload event is triggered), the WebSocket closes, the client detects the closure, waits for the server to come back up, and then reloads the page. The library integrates with Express applications by creating a route to serve the client script, while the CLI tool serves static files and uses nodemon to watch for file changes. The core logic is in `lib/reload.js`, which handles WebSocket server setup, HTTPS support, and parameter validation. The client-side script (`lib/reload-client.js`) is a self-contained pattern that can be reused in other projects. The codebase is well-tested, actively maintained, and follows modern JavaScript practices.