#websocket

WebSocket support for OpenAI Responses API live on AI Gateway

AI Gateway đã bổ sung hỗ trợ chế độ WebSocket cho OpenAI Responses API, cho phép duy trì kết nối liên tục, tiếp tục phiên bằng previous_response_id và thực hiện các phiên thoại theo thời gian thực.

Lập trình viên muốn phát triển ứng dụng giao tiếp thời gian thực với AI hoặc tích hợp OpenAI API vào các hệ thống thực tế cần biết cách tối ưu hóa hiệu suất và tính liên tục của phản hồi bằng WebSocket để giảm thiểu gói dữ liệu và cải thiện trải nghiệm người dùng.

Postgres Changes gets AND filters, new operators, and column selection

Postgres Changes giờ đây hỗ trợ kết hợp bộ lọc bằng toán tử AND, hỗ trợ nhiều toán tử so sánh hơn, và cho phép chọn lọc cột cụ thể trong payload.

Lập trình viên cần đọc bài này để khám phá cách tối ưu hóa và kiểm soát hiệu suất của Change Data Capture (CDC) trong PostgreSQL bằng cách áp dụng các điều kiện AND, các toán tử mới và chọn chỉ những cột cần thiết, giúp giảm tải dữ liệu và cải thiện hiệu quả xử lý trong ứng dụng.

Architectural LED Install Shows How To Do It With Style

Một dự án lắp đặt tường LED kiến trúc sử dụng 928 LED WS2812 điều khiển riêng lẻ thông qua ESP32, tích hợp WebSocket điều khiển thời gian thực, Home Assistant và chế độ phản ứng âm thanh nhờ microphone INMP441 I2S. Điểm nhấn là việc gắn dải LED vào khung vuông đồng tâm hướng vào tường thay vì người xem, tạo hiệu ứng ánh sáng hình học tinh tế mà không cần khuếch tán hay che giấu dải LED.

Là người thiết kế hệ thống IoT hoặc ứng dụng LED, bạn sẽ tìm hiểu cách tối ưu hóa hiệu suất và thẩm mỹ trong các giải pháp ánh sáng thông minh bằng cách kết hợp kiến trúc phần mềm (ESP32) với thiết kế vật lý độc đáo, từ đó nâng cao trải nghiệm người dùng và tiết kiệm chi phí.

Building gateway-go: A Chaos-Engineering Reverse Proxy in Go, Explained End to End

Bài viết giới thiệu cách xây dựng gateway-go, một reverse proxy bằng Go tích hợp kỹ thuật Chaos Engineering, cho phép giám sát mọi request và chủ động phá vỡ hệ thống nhằm kiểm tra khả năng chịu tải.

Nếu bạn muốn tự xây dựng một giải pháp kiểm tra độ bền hệ thống bằng proxy ngầm gói gọn trong Go, từ thiết kế đến triển khai, bài viết sẽ hướng dẫn cách tạo một công cụ như gateway-go—giúp bạn kiểm tra sự ổn định của các dịch vụ trong môi trường thực tế mà không cần phụ thuộc vào công cụ bên ngoài.

Implementing WebSockets in Go using Gorilla WebSocket

Implementing WebSockets in Go using Gorilla WebSocket If you are building a standard CRUD application, suppose a to-do list, HTTP is all you need. The client asks the server for the data, the server …

The Tokio Runtime For Rust: Part III, WebSocket Draining.

Bài viết giới thiệu phần ba trong loạt bài về Tokio Runtime cho Rust, tập trung vào cơ chế "WebSocket draining" nhằm xử lý kết nối WebSocket hiệu quả trong môi trường bất đồng bộ.

Lập trình viên cần đọc bài này để hiểu cách tối ưu hóa xử lý WebSocket trong ứng dụng async bằng Tokio, giúp giảm thiểu chi phí CPU và tối đa hóa hiệu suất khi xử lý nhiều kết nối đồng thời.

I Built a Claude Code Skill That Turns Any Existing Web App Into a Local Vibe Coding Environment

Tác giả đã phát triển một "Skill" tích hợp phiên bản Claude Code chạy cục bộ trực tiếp vào bất kỳ ứng dụng web hiện có, biến nó thành môi trường lập trình "vibe coding" tại chỗ.

Lập trình viên cần đọc bài này để khám phá cách chuyển đổi bất kỳ ứng dụng web hiện có thành một môi trường phát triển trực tiếp trên máy tính, tiết kiệm thời gian và chi phí so với việc phải cài đặt các công cụ độc lập.

Lowering the Drawbridge

Drawbridge 0.4 vừa được phát hành sau 14 năm tồn tại trong tình trạng "bảo trì kỹ thuật". Dự án từng bị coi là bí ẩn nhất trong hệ sinh thái nREPL nhưng nay đang được nâng cấp để hiện thực hóa tiềm năng vốn có.

Lập trình viên nên đọc bài này để khám phá cách Drawbridge – một công cụ ít được biết đến nhưng có thể giải quyết những vấn đề kỹ thuật phức tạp trong việc tương tác với các hệ thống nREPL, giúp tối ưu hóa hiệu suất và khả năng mở rộng cho các ứng dụng lớn.

RCE via Gemini Live AI Voice Session Misconfiguration. Injecting Client-Controlled Setup Frames Through Unconstrained Ephemeral Tokens

A security researcher discovered that Google's Gemini Live API ephemeral token system allows remote code execution when backends issue tokens without populating the live_connect_constraints field. The BidiGenerateContentConstrained WebSocket endpoint is only constrained if the backend explicitly locks session parameters in the token — without this, any authenticated client can inject arbitrary setup frames including system instructions and tools like Python code execution. The vulnerability stems from Google's official reference implementation omitting the constraint configuration, meaning any team following the example ships the same misconfiguration. The fix is adding bidi_generate_content_setup to the token creation call. The sandbox used is gVisor, which limits impact but still allows arbitrary Python execution and compute abuse. The researcher provides a nonce-based proof protocol to distinguish real sandbox execution from model inference.

Building Pingsy: A Decentralized Uptime Monitor Powered by DePIN

Pingsy is a decentralized uptime monitoring system built on DePIN principles, addressing the trust and single-point-of-failure problems of centralized monitors like Pingdom. The architecture uses a TypeScript monorepo with four apps: a Next.js dashboard, an Express API, a Bun WebSocket hub, and a validator daemon. Validators authenticate via Solana Ed25519 keypairs, receive monitoring tasks every 60 seconds, perform HTTP checks, sign results cryptographically, and earn credits per valid check. The hub verifies signatures and records ticks atomically with payout credits in PostgreSQL via Prisma. The frontend shows a 30-minute timeline of 10 status buckets with worst-status-wins logic. The system enables permissionless participation, tamper-evident results, and per-region latency profiling without trusting a single vendor.

Stop mounting your LiveView twice

Phoenix LiveView mounts twice on first page load — once for the static HTTP dead render and again when the WebSocket connects. The common fix of guarding data loads with connected?/1 avoids double queries but breaks SEO, link previews, and no-JS fallback by leaving the dead render empty. This post explains why the double mount exists, what connected?/1 actually costs, and introduces an experimental fork that parks the dead-render socket in a short-lived GenServer and redeems it on WebSocket connect — skipping the second mount entirely. The fork adds an on_connect/1 callback for connection-only side effects (subscriptions, timers, presence) and provides migration patterns for data loads, connect params, and real-time data. The upstream Phoenix team is working on a more complete 'adoptable LiveViews' solution (issue #3551), but this fork serves as an interim stopgap.

Choose your fighter: benchmarking 5 WebSocket servers for Node.js—Martian Chronicles, Evil Martians’ team blog

A deep dive into benchmarking five Node.js WebSocket servers: default Socket.io, Socket.io with Connection State Recovery, uWebSockets.js, AnyCable OSS, and AnyCable Pro. The post documents two major measurement traps: a saturated single-process load generator that inflated AnyCable's p99 latency from 11ms to 234ms, and a real throughput gap between AnyCable and uWS that turned out to be genuine. Key methodology lessons include running the load generator co-located with servers, sharding clients across multiple processes to avoid event loop saturation, equalizing reconnect backoff windows across libraries, and always validating surprising results with a second independent measurement. Final results show all five servers within a few milliseconds at 10K subscribers, but AnyCable leads on 100% message delivery under network drops, deploy-time reconnect storms, and broadcast throughput at scale, while uWS is lightest per connection and Socket.io caps around 120K connections per node.