# RPC Published articles for RPC. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Bringing QUIC to Seastar DevFeed: [Bringing QUIC to Seastar]() Original publisher: [Read original article]() Author: Cynthia Dunlop Published: 2026-09-14T13:02:07Z Content type: article Language: en Sources: [ScyllaDB]() Topics: [Seastar](), [networking](), [Remote Procedure Call (RPC)](), [C++](), [Latency](), [Protocol (disambiguation)]() Tags: [benchmarks](), [c-plus-plus](), [collaboration](), [engineering](), [latency](), [network](), [networking](), [rpc](), [scylladb](), [seastar](), [udp]() ### AI overview This article describes a University of Warsaw student project conducted with ScyllaDB to implement a QUIC transport for Seastar using the sans-I/O ngtcp2 library. It also adapts Seastar's RPC layer to operate over QUIC and reports benchmark results showing predictable overhead on a lossless loopback and benefits when packets are dropped. ### Source excerpt We built a QUIC transport for Seastar on top of ngtcp2's sans-I/O state machine, then adapted RPC to it twice: 1) as a one-to-one socket replacement, and 2) a QUIC-aware approach that opens a fresh stream per call. ## 🍔🧠 How OpenAI Built GPT-Live for Low-Latency Voice AI DevFeed: [🍔🧠 How OpenAI Built GPT-Live for Low-Latency Voice AI]() Original publisher: [Read original article]() Author: Alexandre Zajac Published: 2026-09-07T15:31:33Z Content type: article Language: en Sources: [Hungry Minds]() Topics: [Conversational AI](), [Low Latency](), [voice ai](), [OpenAI](), [real-time](), [Streaming](), [Remote Procedure Call (RPC)](), [Go]() Tags: [go](), [low-latency](), [openai](), [real-time](), [rpc](), [software-engineering](), [streaming](), [voice-ai]() ### AI overview The article explains how OpenAI built GPT-Live as a low-latency, full-duplex voice system. It describes a fast audio path that listens and speaks simultaneously, asynchronous delegation of deeper reasoning and backend work, stateful handoffs, optimized protocol boundaries, and a Go-based media frontend. ### Source excerpt PLUS: Zero-knowledge proofs ⚡, Design.md agent automation 👨💻, System Design Docs 101 📚 ## MCP Logging in Spring AI DevFeed: [MCP Logging in Spring AI]() Original publisher: [Read original article]() Author: Burak Gökmen Published: 2026-09-06T23:19:21Z Content type: tutorial Language: en Sources: [Baeldung]() Topics: [Model Context Protocol](), [log management](), [AI Development](), [Remote Procedure Call (RPC)](), [telemetry]() Tags: [logging](), [mcp](), [mcp-server](), [opentelemetry](), [popular](), [rpc](), [spring](), [spring-ai](), [spring-ai-mcp-popular](), [spring-boot](), [tutorial]() ### AI overview A tutorial on MCP logging in Spring AI, covering server-to-client log notifications, client-controlled severity levels, and migration guidance following the feature's deprecation. ### Source excerpt Learn about MCP logging in Spring AI, both in an MCP server and a client. The post MCP Logging in Spring AI first appeared on Baeldung. ## Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads DevFeed: [Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads]() Original publisher: [Read original article]() Author: Jeffrey Ying Published: 2026-09-01T18:30:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [Remote Procedure Call (RPC)](), [Caching]() Tags: [cache](), [kubernetes](), [memory](), [releases](), [rpc](), [streaming]() ### AI overview Kubernetes v1.37 promotes etcd RangeStream to beta. With etcd v3.7, streamed collection reads reduce and stabilize memory use by processing chunks instead of assembling entire pages. ### Source excerpt I am excited to announce that etcd RangeStream is graduating to beta in Kubernetes v1.37. Paired with etcd v3.7, it reduces the memory the API server and etcd need to read a large collection, and makes peak usage more predictable. The cost of large reads The API server serves most list and watch requests from its in-memory watch cache. Populating that cache requires reading a resource's full state from etcd, at startup and on every re-initialization. For a resource with many objects, or large ones, such as Pods, that read is expensive. The API server already paginated these reads, asking etcd for a fixed number of keys at a time rather than the whole collection at once. But a page bounded by key count has no awareness of object size, so a page of large objects can still be very large. That makes memory usage hard to predict, and a bad combination of object size and concurrent reads can be enough to trigger an OOM. etcd's unary Range assembles each page in full before sending it, and the API server holds it while decoding, so the same payload sits in memory on both sides at once. Most of that cost lands on etcd, which is also where streaming helps most. Streaming reads with RangeStream etcd v3.7 adds a streaming version of that read, the RangeStream RPC. It takes the same RangeRequest as Range and returns the same result set, but instead of building the whole response up front, etcd splits it into chunks and streams them. Chunk size is tuned adaptively to the values being returned, so a collection of large objects is bounded by bytes rather than by a key count, and memory is freed as the stream progresses instead of being held until a whole page is assembled. When the feature is enabled, the API server uses RangeStream wherever it reads a whole collection out of etcd. This includes watch cache initialization, and the fallback paths where a list request cannot be served from the cache and reads etcd directly. In either case the API server decodes each chunk as it arri ## 【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted DevFeed: [【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Remote Procedure Call (RPC)](), [Kubernetes]() Tags: [apiserver](), [apply](), [compaction](), [distributed](), [errcompacted](), [etcd](), [io](), [k8s](), [kubernetes](), [lag](), [leader](), [lease](), [mvcc](), [notify](), [raft](), [range](), [restore](), [revision](), [rpc](), [v3-5](), [v3-5-33](), [watch](), [watchablestore]() ### AI overview This article examines the etcd v3.5.33 watchableStore implementation, including synced and unsynced watcher groups, victims caused by backpressure, Apply-time notification, historical synchronization, and the ErrCompacted client resynchronization boundary. It also discusses event ordering, follower watch progress, and interactions with Kubernetes apiserver watch caches. ### Source excerpt 钉 etcd v3.5.33 watchableStore 的 synced/unsynced/victims 三分法、Apply 后 notify 与历史追赶 syncWatchersLoop，以及 CompactRevision 触发 ErrCompacted 时的客户端重同步边界。 ## Develop and test MCP in Postman: jhipster-mcp in action DevFeed: [Develop and test MCP in Postman: jhipster-mcp in action]() Original publisher: [Read original article]() Author: Anthony Viard Published: 2026-08-19T16:00:00Z Content type: article Language: en Sources: [Postman Blog]() Topics: [Model Context Protocol](), [Postman](), [Spring Boot](), [Node.js](), [TypeScript](), [Angular](), [React](), [Vue.js](), [JSON](), [Remote Procedure Call (RPC)]() Tags: [ai-agents](), [angular](), [apache](), [cli](), [general](), [jhipster](), [json](), [mcp](), [node-js](), [open-source](), [post](), [react](), [rpc](), [spring-boot](), [typescript](), [vue]() ### AI overview This Postman developer article demonstrates jhipster-mcp, an open-source MCP server that exposes the JHipster generator to MCP clients. It uses Postman's MCP client to test tools, prompts, and resources for generating and evolving Spring Boot applications from JDL. ### Source excerpt Drive the jhipster-mcp server from Postman's MCP client to test tools, prompts, and resources before handing them to an AI agent. Try it today. The post Develop and test MCP in Postman: jhipster-mcp in action appeared first on Postman Blog. ## v1 Transactions and the ALT Trade-off DevFeed: [v1 Transactions and the ALT Trade-off]() Original publisher: [Read original article]() Author: Umberto Natale Published: 2026-08-17T00:00:00Z Content type: article Language: en Sources: [Solana News Feed]() Topics: [Solana](), [Transactions](), [benchmarking](), [SDKs]() Tags: [blockchain](), [blockchain-technology](), [crypto-news](), [cryptocurrency](), [defi](), [nfts](), [podcasts](), [reference](), [reports](), [rpc](), [sdks](), [serialization](), [solana](), [solana-ecosystem](), [transactions](), [upgrades](), [web3]() ### AI overview Solana is introducing the v1 transaction format with a maximum serialized size of 4,096 bytes, replacing Account Lookup Table resolution with larger inline transaction capacity. The analysis finds that current workloads are broadly compatible with the new envelope, while the unchanged 64-account limit may remain a constraint for some applications. ### Source excerpt Solana is introducing a new transaction format (v1) alongside an increase of the maximum transaction size from 1232 bytes to 4096 bytes. The v1 format aims to unlock new possibilities on-chain. This is done trading-off Account Lookup Tables (ALT) usage. In this research we explore in details the current usage of ALTs, alongside implications of removing them. ## MCP vs API DevFeed: [MCP vs API]() Original publisher: [Read original article]() Author: Roger Perkin Published: 2026-08-14T07:35:02Z Content type: article Language: en Sources: [Roger Perkin Network Automation Consultant]() Topics: [MCP vs API](), [API](), [Model Context Protocol](), [AI Models](), [Protocol (disambiguation)]() Tags: [ai-models](), [api](), [json-rpc](), [mcp](), [mcp-vs-api](), [rest-apis](), [rpc](), [vs]() ### AI overview This article explains that MCP and APIs serve different purposes. APIs connect software systems through predefined endpoints, while MCP lets AI models discover and use tools dynamically. MCP does not replace APIs; it operates on top of existing APIs as a standardized, AI-friendly translation layer. ### Source excerpt Ever since MCP became popular, I hear people saying "does MCP replace APIs?" Or do they both solve completely different problems? Firstly the facts: APIs connect software systems through predefined endpoints, while MCP enables AI models to discover and use tools dynamically. So, they are two different things, but can MCP replace APIs? More discussions ... ## Go SDK для YDB: уменьшаем количество запросов к СУБД для интерактивных транзакций DevFeed: [Go SDK для YDB: уменьшаем количество запросов к СУБД для интерактивных транзакций]() Original publisher: [Read original article]() Author: spesternikov (Яндекс, Yandex Cloud & Yandex Infrastructure, YDB) Published: 2026-08-13T13:23:34Z Content type: tutorial Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [Go](), [SDKs](), [Transactions](), [Remote Procedure Call (RPC)]() Tags: [go](), [rpc](), [sdk](), [tag-8288660a1e40](), [tag-89f0c6f39f5d](), [tag-d4be1d74f775](), [transactions](), [ydb]() ### AI overview This Russian-language technical article explains how Yandex's YDB Go SDK reduces network round-trips for interactive transactions. It describes combining transaction startup with the first query through Lazy Transactions and notes that the improvements were included in Go SDK releases v3.126.0 and v3.126.5. ### Source excerpt Привет, Хабр! Меня зовут Степан Пестерников, мы с командой делаем Алису и активно используем СУБД Яндекса. Недавно коллеги из YDB провели большой рефакторинг в YDB Go SDK, где по умолчанию теперь используется новый Query Service. Я воспользовался этим рефакторингом, чтобы уменьшить количество сетевых запросов от SDK к YDB. Клиентские SDK устанавливают к распределённой СУБД Яндекса gRPC-подключения, поверх которых отправляются низкоуровневые команды. Какие-то из этих команд можно объединять: например, команду начала транзакции и выполнения первого запроса. В статье я покажу фрагменты кода и расскажу, как мы делали улучшения, которые вошли в релизы v3.126.0 и v3.126.5 Go SDK. Фрагменты кода получились небольшие, и на их примере удобно показать, как этими оптимизациями пользоваться. Читать далее ## Kimwolf v7: An Evolution of the Kimwolf Botnet DevFeed: [Kimwolf v7: An Evolution of the Kimwolf Botnet]() Original publisher: [Read original article]() Author: Asher Davila, Chris Navarrete and Doel Santos Published: 2026-08-11T10:00:16Z Content type: article Language: en Sources: [Unit 42]() Topics: [Kimwolf v7](), [Android](), [DDoS](), [Internet of things](), [C2](), [Ethereum Name Service (ENS)](), [Malware](), [Cybercrime](), [Ethereum](), [Blockchain](), [Routing (disambiguation)](), [Threat Hunting & Intel]() Tags: [android](), [android-apk](), [blockchain](), [c2](), [ddos](), [devices](), [ethereum](), [http](), [iot-botnets](), [kimwolf-v7](), [linux](), [malware](), [network](), [networks](), [resilience](), [routing](), [rpc](), [spoofing](), [threat-research]() ### AI overview Kimwolf v7 is an Android and IoT botnet variant that adds HTTP/2-based DDoS flooding with browser fingerprinting, Ethereum Name Service resolution for C2 addresses, and Tor-backed routing to improve infrastructure resilience. The article also describes its targeting of Android TV devices and exploitation of unauthenticated ADB instances. ### Source excerpt Discover how Kimwolf v7 targets Android IoT devices with HTTP/2 DDoS fingerprinting, Ethereum ENS C2 resolution and Tor backup routing. The post Kimwolf v7: An Evolution of the Kimwolf Botnet appeared first on Unit 42. ## The Permanent Threat: Analyzing Aeternum's Blockchain-Based C2 Operations and Communications DevFeed: [The Permanent Threat: Analyzing Aeternum's Blockchain-Based C2 Operations and Communications]() Original publisher: [Read original article]() Author: Chris Navarrete, Sai Sathvik Ruppa and Haozhe Zhang Published: 2026-08-10T22:00:02Z Content type: article Language: en Sources: [Unit 42]() Topics: [Aeternum](), [C++](), [Firewall]() Tags: [aeternum](), [analysis](), [blockchain](), [c-plus-plus](), [c2](), [infection-chain](), [json](), [malware](), [python](), [rpc](), [telegram](), [threat-research](), [xmrig](), [xor]() ### AI overview An analysis of the Aeternum botnet loader, which uses Polygon blockchain smart contracts and public RPC endpoints for decentralized command-and-control. It also examines related Python malware using the Telegram API and a blended threat involving XWorm RAT, XMRig, and data exfiltration. ### Source excerpt Analysis of the Aeternum botnet loader, a threat leveraging Polygon blockchain smart contracts for decentralized C2 infrastructure and payload execution. The post The Permanent Threat: Analyzing Aeternum's Blockchain-Based C2 Operations and Communications appeared first on Unit 42. ## When does the A2A protocol actually matter? DevFeed: [When does the A2A protocol actually matter?]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-08-04T00:00:00Z Content type: article Language: en Sources: [Redis Blog]() Topics: [Protocol (disambiguation)](), [Model Context Protocol](), [Remote Procedure Call (RPC)](), [Security](), [JSON](), [Authentication](), [Web]() Tags: [authentication](), [http](), [json](), [mcp](), [model-context-protocol](), [rpc](), [security](), [server](), [tech-de]() ### AI overview A2A is an open standard for communication between independently deployed agents, particularly when they are owned by different teams or vendors. The article presents an ownership test for deciding whether A2A is needed, explains its security model and core primitives, and contrasts it with MCP. ### Source excerpt If you're building multi-agent systems, someone has probably asked whether you're "doing A2A yet," with the implication that you should be. When teams actually reach for it, most can't say why they need A2A over MCP. A more useful question: do your ag... ## What's new in the MCP 2026-07-28 specification DevFeed: [What's new in the MCP 2026-07-28 specification]() Original publisher: [Read original article]() Author: Aditya Oberai Published: 2026-07-30T00:00:00Z Content type: tutorial Language: en Sources: [Appwrite Blog]() Topics: [Model Context Protocol](), [MCP Server](), [HTTP](), [Routing (disambiguation)](), [Caching](), [Authorization](), [Remote Procedure Call (RPC)]() Tags: [caching](), [http](), [mcp](), [mcp-server](), [model-context-protocol](), [news](), [routing](), [rpc]() ### AI overview The article explains changes in the MCP 2026-07-28 specification, focusing on the move from stateful sessions to a stateless request/response core. It covers implications for routing, load balancing, caching, authorization, and server migration. ### Source excerpt The MCP 2026-07-28 spec drops sessions, adds header based routing, cacheable lists, and MRTR. Here is what changed and what you need to migrate your servers. ## Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need? DevFeed: [Model Context Protocol (MCP) vs. Agent2Agent (A2A): which protocol do you need?]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-07-22T00:00:00Z Content type: comparison Language: en Sources: [Redis Blog]() Topics: [Model Context Protocol](), [Remote Procedure Call (RPC)](), [Artificial Intelligence](), [JSON](), [Large Language Model](), [Orchestration](), [observability](), [servers](), [Grafana]() Tags: [agent](), [api](), [architecture](), [developer](), [developer-tooling](), [grafana](), [guide](), [json](), [mcp](), [model-context-protocol](), [observability](), [rpc](), [tech-de]() ### AI overview This guide compares the Model Context Protocol (MCP) with Agent2Agent (A2A), explaining that MCP connects an LLM application to tools and data while A2A connects independent agents. It describes MCP's hosts, clients, servers, tools, resources, prompts, JSON-RPC transport, streaming, production use cases, and governance limitations. ### Source excerpt Somewhere around your third agent, someone in a design review asks, "Shouldn't we be using A2A for this?" It's a fair question that most teams can't answer well, because the two big agent protocols keep getting lumped together when they solve differen... ## 5 agent architecture scenarios: assess MCP vs. A2A DevFeed: [5 agent architecture scenarios: assess MCP vs. A2A]() Original publisher: [Read original article]() Author: Jeff Mills Published: 2026-07-22T00:00:00Z Content type: article Language: en Sources: [Redis Blog]() Topics: [Model Context Protocol](), [Remote Procedure Call (RPC)](), [JSON](), [Large Language Model](), [anthropic]() Tags: [agent](), [anthropic](), [apis](), [architecture](), [article](), [data](), [external](), [json](), [llms](), [mcp](), [rpc](), [server](), [tech-de]() ### AI overview An analysis of five agent architecture scenarios, using the boundary between an agent and external tools or data, and the boundary between agents, to clarify when MCP or A2A is appropriate. It explains MCP's client-host-server model and JSON-RPC exchanges, contrasts it with A2A, and emphasizes that neither protocol is universally required. ### Source excerpt We've watched enterprise teams go from vague "we might do agent stuff" conversations to full internal agent environments in a matter of months, and the same protocol question comes up in almost every one: does the design need the Model Context Protoco... ## Your Codename One App Can Be an MCP Server DevFeed: [Your Codename One App Can Be an MCP Server]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-07-21T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [MCP Server](), [Model Context Protocol (MCP)](), [ui](), [Accessibility](), [App]() Tags: [accessibility](), [agents](), [coding-agents](), [json](), [mcp](), [mcp-server](), [process](), [rpc](), [standard](), [ui]() ### AI overview The article explains how a running Codename One simulator or JavaSE desktop tool can expose its semantic UI and application tools through a local Model Context Protocol server. MCP hosts can inspect forms, interact with labeled fields and buttons, and invoke domain tools while actions run on the event dispatch thread and return fresh state snapshots. ### Source excerpt A running Codename One simulator or JavaSE tool can expose its semantic UI and application tools to coding agents over MCP. ## Announcing etcd v3.7.0 DevFeed: [Announcing etcd v3.7.0]() Original publisher: [Read original article]() Author: SIG Etcd Leads Published: 2026-07-08T12:00:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [releases](), [Database](), [Kubernetes](), [Latency](), [Remote Procedure Call (RPC)]() Tags: [changelog](), [cpu](), [database](), [kubernetes](), [latency](), [memory](), [performance](), [release](), [releases](), [rpc]() ### AI overview etcd v3.7.0 is a minor release of the distributed key-value store used as a core Kubernetes component. It introduces RangeStream for chunked large result sets, improves performance and leases, removes the legacy v2store, and completes a protobuf overhaul. ### Source excerpt This article is a mirror of the original announcement Today, SIG etcd is releasing etcd v3.7.0, the latest minor release of the popular distributed key-value store and core Kubernetes component. v3.7 ships the long-requested RangeStream feature, delivers several other performance improvements, removes the last remnants of the legacy v2store, and completes a major protobuf overhaul. You can download etcd v3.7.0 here: Source code Binaries Official container images This release also includes new versions of the two core etcd dependencies, bbolt v1.5.0 and raft v3.7.0. For instructions on installing etcd, see the install documentation. For the full list of changes, see the etcd v3.7 changelog. A heartfelt thank you to all the contributors who made this release possible! Major features The most significant changes in v3.7.0 include: RangeStream -- stream large result sets in chunks instead of buffering the whole response. Keys-only range requests, faster and more reliable leases, and several other performance improvements. etcd now boots entirely from v3store, eliminating a long-standing dependency on the legacy v2 store A completed protobuf overhaul, replacing outdated protobuf libraries with fully supported ones. etcd v3.7 ships with bbolt v1.5.1 and raft v3.7.0. FeaturesRangeStream In etcd v3.6 and earlier, it is challenging to work with requests that return large result sets. The database would buffer the full result set before sending, leading to unpredictable latency and memory usage, both on the server and the client. The RangeStream RPC lets calling applications accept result sets in chunks, reducing latency and making buffering memory usage more predictable. Instructions on how to use RangeStream in gRPC calls and in etcdctl can be found in the etcd documentation. Users should try it out for their own applications. In coordinated releases, the RangeStream feature will become available to users running the upcoming v1.37 of Kubernetes by enabling the EtcdRangeStre ## Security Baked Into the JVM: why fork Apache River and OpenJDK? DevFeed: [Security Baked Into the JVM: why fork Apache River and OpenJDK?]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-06-28T00:00:00Z Content type: opinion Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [Java](), [openjdk](), [Architecture & Design](), [Remote Procedure Call (RPC)](), [Networks]() Tags: [authorization](), [dirtychai](), [discovery](), [distributed](), [ipv6](), [java](), [jgdms](), [jini](), [jvm](), [lock-free](), [microservices](), [openjdk](), [rpc](), [security](), [self-healing](), [technical]() ### AI overview This article introduces DirtyChai, a community fork of OpenJDK that restores Java authorization infrastructure, and JGDMS, a security-hardened fork of Apache River for dynamically discoverable microservices over IPv6. It argues that distributed systems require security beyond network firewalls and outlines the projects' complementary roles, including authorization, service discovery, hardened deserialization, transport security, proxy trust verification, and codebase safety checks. ### Source excerpt The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn't notice. ## How to Design APIs DevFeed: [How to Design APIs]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-06-02T06:41:25Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [API](), [Architecture & Design](), [interface](), [CRUD](), [GraphQL](), [gRPC](), [HTTP](), [JSON](), [XML]() Tags: [api](), [apis](), [crud](), [graphql](), [how-to](), [http](), [interface](), [json](), [rest](), [rpc]() ### AI overview A tutorial on API design covering interface contracts, resource and endpoint naming, request and response formats, API paradigms, and modeling relationships between entities. ### Source excerpt Key considerations to keep in mind ## wasmCloud 2.2.0: TLS for WebAssembly, customizable HTTP egress DevFeed: [wasmCloud 2.2.0: TLS for WebAssembly, customizable HTTP egress]() Original publisher: [Read original article]() Author: Eric Gregory Published: 2026-05-21T00:00:00Z Content type: release Language: en Sources: [wasmCloud Blog]() Topics: [WebAssembly](), [HTTP](), [TLS (Transport Layer Security)]() Tags: [config](), [handler](), [hardening](), [http](), [middleware](), [release](), [rpc](), [tls](), [wasi](), [webassembly]() ### AI overview wasmCloud 2.2.0 adds native TLS for WebAssembly components through WASI Preview 3, a pluggable HTTP egress handler, an expanded wash config command, and runtime-operator hardening. The release also supports customizable TLS providers and embedder-controlled outbound request handling. ### Source excerpt wasmCloud 2.2.0 brings WASI Preview 3 TLS to WebAssembly components, a pluggable OutgoingHandler trait for HTTP egress, an expanded wash config command, and runtime-operator hardening. ## Announcing etcd 3.7.0-beta.0 DevFeed: [Announcing etcd 3.7.0-beta.0]() Original publisher: [Read original article]() Author: SIG-etcd Leads Published: 2026-05-20T00:00:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Databases](), [Remote Procedure Call (RPC)](), [Kubernetes](), [Refactoring](), [Code quality]() Tags: [availability](), [code-quality](), [database](), [kubernetes](), [latency](), [refactoring](), [release](), [rpc]() ### AI overview The article announces the first beta release of etcd v3.7.0, introducing the RangeStream RPC for processing large result sets in chunks. It also describes legacy-component cleanup, the removal of v2store, and expected upgrade compatibility issues. ### Source excerpt SIG-Etcd announces the availability of the first beta release of etcd v3.7.0. This new version of the popular distributed database and key Kubernetes component includes the long-requested RangeStream feature, as well as a refactoring and cleanup of multiple legacy components and interfaces. v3.7 will deliver improved security, better operational reliability, and an improved experience for working with large resultsets. First, however, the project needs users to test the beta. You can find v3.7.0-beta.0 here: Source code Binaries Official container images Please try it out and report issues in the etcd repo. This beta also determines the EOL of version 3.4. RangeStream In etcd v3.6 and earlier, it is challenging to work with requests that return large resultsets. The client or requesting application is forced to wait for the full result set, leading to unpredictable latency and memory usage. The RangeStream RPC lets calling applications accept result sets in chunks, reducing latency and making buffering memory usage more predictable. Much of the work on RangeStream was done by a relatively new contributor to etcd, Jeffrey Ying, a software engineer at Google. New contributors can have a substantial impact on etcd development. "I've always been fascinated by database internals, and building RangeStream was a great opportunity to solve a bottleneck we were hitting in production with Kubernetes. It was the perfect opportunity to collaborate across projects and improve the ecosystem as a whole. Jumping into etcd as a new contributor had a bit of a learning curve, but the community is incredibly welcoming. The leads were very receptive to my ideas and helped me iterate quickly, while maintaining the project's high bar for reliability and code quality," said Jeffrey. Instructions on how to use RangeStream in gRPC calls and in etcdctl can be found in the etcd documentation. Users should try it out for their own applications. Removal of v2store The last vestiges of etcd v2sto ## Announcing Lix 2.95 "Kakigōri" DevFeed: [Announcing Lix 2.95 "Kakigōri"]() Original publisher: [Read original article]() Published: 2026-03-25T00:00:00Z Content type: release Language: en Sources: [News on Lix]() Topics: [releases](), [Cap'n Proto](), [Remote Procedure Call (RPC)](), [Nix]() Tags: [bugfixes](), [documentation](), [improvements](), [performance](), [release](), [rpc](), [upgrade](), [version]() ### AI overview The Lix team announces version 2.95, "Kakigōri," a major release focused on bug fixes, quality-of-life improvements, documentation, performance, and continued integration with the Cap'n Proto RPC runtime. The article also describes upgrade guidance and ongoing work toward additional RPC protocols. ### Source excerpt We at the Lix team are proud to announce our sixth major release, version 2.95 "Kakigōri". This release focuses on long-awaited bugfixes, quality-of-life improvements, documentation, performance improvements and continued integration of Lix with the Cap'n'Proto remote procedure call runtime to replace the previous bespoke implementation. ## Transitioning from REST to gRPC: System Design and Tradeoffs DevFeed: [Transitioning from REST to gRPC: System Design and Tradeoffs]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [gRPC](), [Remote Procedure Call (RPC)](), [Code](), [HTTP](), [JSON]() Tags: [api-design](), [client](), [grpc](), [http](), [json](), [microservices](), [protobuf](), [rest](), [rpc](), [schema](), [server](), [system-design]() ### AI overview This tutorial explains how gRPC uses .proto service definitions and Protocol Buffers to generate typed client and server code, serialize messages, and communicate over HTTP/2. It compares gRPC with REST and recommends gRPC for internal service-to-service calls needing low latency, schema-first contracts, or streaming, while retaining REST with JSON at the edge for browsers and external consumers. ### Source excerpt gRPC defines services in a .proto file, compiles them into typed client and server code, and transports binary protobuf over HTTP/2. Choose it for internal service-to-service calls that need low latency, schema-first contracts, or streaming, and keep REST with JSON at the edge where browsers and external consumers live. ## Anatomy of a trace DevFeed: [Anatomy of a trace]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-03-02T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [tracing](), [Traces](), [telemetry](), [API](), [Databases](), [Cache](), [Remote Procedure Call (RPC)](), [HTTP](), [SQL](), [Authentication]() Tags: [api](), [authentication](), [cache](), [database](), [distributed](), [http](), [request](), [rpc](), [sql](), [trace](), [tracing]() ### AI overview This article explains how distributed traces are built as requests move through services and operations. It describes root and child spans, trace IDs, automatic context propagation, and the operation-specific data captured by Encore's runtime, including API calls, RPCs, database queries, cache writes, and outbound HTTP calls. ### Source excerpt What actually happens when a request hits your application, and what a distributed trace captures at every step. [Next page]()