# gRPC gRPC is a modern open-source, high-performance Remote Procedure Call (RPC) framework for connecting services across environments, including distributed systems and backend applications. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Scheduling gRPC and GraphQL Requests with Postman Monitors (Beta) DevFeed: [Scheduling gRPC and GraphQL Requests with Postman Monitors (Beta)]() Original publisher: [Read original article]() Author: Harsh Vardhan Published: 2026-09-16T16:00:00Z Content type: tutorial Language: en Sources: [Postman Blog]() Topics: [gRPC](), [Postman](), [Monitoring](), [Authentication]() Tags: [beta](), [general](), [graphql](), [graphql-monitoring](), [how-to](), [monitor-grpc-streaming](), [monitoring](), [monitors](), [postman](), [postman-monitors-grpc-graphql](), [scheduling](), [test]() ### AI overview This tutorial explains how to schedule gRPC and GraphQL requests with Postman Monitors in beta. It covers supported request types, streaming caveats, response testing, authentication, and current feature limitations. ### Source excerpt Postman Monitors now run gRPC and GraphQL requests in beta. Learn how to schedule them, test responses, and send feedback. Start monitoring today. The post Scheduling gRPC and GraphQL Requests with Postman Monitors (Beta) appeared first on Postman Blog. ## Logpoints Walkthrough DevFeed: [Logpoints Walkthrough]() Original publisher: [Read original article]() Author: Igor Kulakov Published: 2026-09-16T14:14:04Z Content type: tutorial Language: en Sources: [The JetBrains Blog]() Topics: [IntelliJ IDEA](), [debug](), [debugging](), [gRPC](), [Java](), [2026.2]() Tags: [2026-2](), [bug](), [client](), [command-line](), [debug](), [debugger](), [debugging](), [debugging-tools](), [idea](), [intellij](), [intellij-idea](), [java](), [kotlin](), [logpoints]() ### AI overview This walkthrough explains how to use logpoints in IntelliJ IDEA to investigate a bug in a gRPC client-server example that returns incorrect discount values. It covers reproducing the issue, attaching the debugger to the server, and observing program behavior without suspending execution, including improvements in IntelliJ IDEA 2026.2. ### Source excerpt Modern development tools, especially IntelliJ IDEA, have such comprehensive debugging support that for virtually any niche use case, there is a specialized tool for the job. This can make it hard to know where to begin. If you are new to debugging tools and want the biggest return on your learning investment, the best feature [...] ## Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta DevFeed: [Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta]() Original publisher: [Read original article]() Author: Kevin Torres Martinez Published: 2026-09-15T18:30:00Z Content type: release Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [cpu](), [Hardware](), [Latency](), [API](), [gRPC](), [Monitoring]() Tags: [api](), [cpu](), [hardware](), [kubernetes](), [latency](), [monitoring](), [numa](), [release](), [v1]() ### AI overview Kubernetes v1.37 graduates Pod-Level Resource Managers to Beta, disabled by default. The feature lets Kubelet resource managers use pod-level declarations for hardware placement, enabling NUMA-aligned exclusive resources for primary containers while placing sidecars in a shared pod-isolated pool. The release also adds pod-level reporting to the PodResources gRPC API. ### Source excerpt With the release of Kubernetes v1.37, the Pod-Level Resource Managers feature has graduated to Beta status (disabled by default)! First introduced as an Alpha feature in Kubernetes v1.36, this enhancement builds on Pod-Level Resources by equipping Kubelet's Topology Manager, CPU Manager, and Memory Manager to use Pod-level resource declarations (.spec.resources) directly when making hardware placement decisions. Bringing pod-level resources to node managers Before this feature, obtaining exclusive NUMA-aligned CPU cores or memory for latency-critical applications forced cluster operators into an all-or-nothing choice: assign integer resource requests to every container in the Pod, or forfeit exclusive NUMA alignment entirely. For modern workloads running lightweight sidecars (such as logging agents or telemetry exporters), allocating dedicated physical cores to auxiliary containers was wasteful. Pod-Level Resource Managers solves this challenge by enabling hybrid allocation models. The Kubelet can reserve exclusive NUMA-aligned resources for primary application containers while placing non-Guaranteed sidecars into a pod-isolated shared pool. This ensures primary workloads get unthrottled, NUMA-local performance while sidecars benefit from running in a pod-isolated shared pool, enjoying local NUMA alignment and protection from external node interference without consuming dedicated physical cores. What's new in Beta Graduating to Beta brings key operational and API enhancements: Graduation to Beta: Controlled by the PodLevelResourceManagers feature gate, available to opt in (disabled by default) in Kubernetes v1.37. PodResources API Reporting: The v1 PodResources gRPC service (PodResourcesLister) introduces top-level cpu_ids and memory fields on PodResources responses. Monitoring tools and device plugins can query pod-level exclusive assignments directly without double-counting container allocations. Getting started and providing feedback For a deep dive into the tech ## Kubernetes Changed Block Tracking API - Beta Differences DevFeed: [Kubernetes Changed Block Tracking API - Beta Differences]() Original publisher: [Read original article]() Author: Prasad Ghangal Published: 2026-09-14T18:30:00Z Content type: article Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [API](), [gRPC]() Tags: [2026](), [compatibility](), [container-image-registry](), [developer](), [documentation](), [kubernetes](), [registry](), [release](), [snapshots](), [storage](), [streaming](), [update]() ### AI overview This Kubernetes developer article explains the Beta changes to Changed Block Tracking (CBT) support for CSI drivers. The SnapshotMetadataService CRD moved from v1alpha1 to v1beta1, with no automatic conversion, and CBT remains limited to block volumes. It also outlines compatibility requirements and the steps for upgrading and trying the feature. ### Source excerpt Changed Block Tracking (CBT) support for CSI drivers shipped as Alpha in September 2025. With the March 2026 v1.0.0 release of the external-snapshot-metadata project, the feature moved to Beta. If you aren't yet familiar with changed block tracking for storage in Kubernetes, the Alpha announcement covers the motivation, the three primary components (the CSI SnapshotMetadata gRPC service, the SnapshotMetadataService CRD, and the external-snapshot-metadata sidecar), and a walkthrough of how to use the API. CBT currently applies to block volumes; file-volume and network file-share changed-list tracking is not covered by this feature. This post focuses on what is different in Beta. What's new in Beta The main change in that release was the promotion of the SnapshotMetadataService CRD from v1alpha1 to v1beta1. The CRD used to advertise a driver's metadata service now serves cbt.storage.k8s.io/v1beta1. The schema itself is unchanged, but this release removed v1alpha1 (rather than serving it alongside the new version). If you are upgrading from Alpha, you need to: Re-apply the CRD definition shipped with v1.0.0. Update SnapshotMetadataService manifests to use apiVersion: cbt.storage.k8s.io/v1beta1. Update any client or controller code that talks to the CRD. This is a one-time change. There is no automatic conversion between the two versions. Compatibility Minimum Kubernetes version: 1.33 CSI spec: 1.10 or newer Container image: registry.k8s.io/sig-storage/csi-snapshot-metadata:v1.0.0 Trying it out The Getting Started section in the Alpha blog still applies. In short: Make sure your CSI driver supports volume snapshots and ships the external-snapshot-metadata sidecar. Install the SnapshotMetadataService CRD (the v1beta1 definition from the v1.0.0 release). Create a SnapshotMetadataService resource for your driver. Use a client -- snapshot-metadata-lister, or your own implementation -- to call GetMetadataAllocated and GetMetadataDelta. If you want to see the full flow end-to-e ## Scaling real-time AI agents with session-aware load balancing DevFeed: [Scaling real-time AI agents with session-aware load balancing]() Original publisher: [Read original article]() Author: Simerus Mahesh Published: 2026-09-12T11:04:33.891311Z Content type: article Language: en Sources: [Google Developers Blog]() Topics: [real-time](), [Artificial Intelligence](), [Streaming](), [Server](), [gRPC](), [WebSocket](), [cpu](), [Concurrent Programming]() Tags: [ai-agents](), [concurrent](), [cpu](), [real-time](), [routing](), [server](), [streaming]() ### AI overview This article explains why real-time AI agents require session-aware load balancing. Long-lived, stateful bidirectional streams make request rates and CPU utilization insufficient measures of backend capacity. The proposed approach tracks active sessions at the application level and combines session counts with CPU metrics to distribute traffic and avoid bottlenecks. ### Source excerpt Real-time AI agents break traditional request-response load balancing paradigms because they rely on long-lived, stateful bidirectional streams that obscure true server capacity. To solve this, developers must implement application-level session tracking directly within the runtime to accurately measure the committed concurrent workload of active conversations. By feeding these precise session counts alongside standard CPU utilization metrics into a hybrid routing algorithm, infrastructure can effectively distribute stateful AI traffic and prevent individual backend bottlenecks. ## 【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由 DevFeed: [【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [gRPC]() Tags: [apiserver](), [apply](), [atomic](), [commit](), [compaction](), [distributed](), [etcd](), [etcdserver](), [follower](), [kubernetes](), [leader](), [learner](), [linearizable](), [raft](), [request](), [single-raft-group](), [v3](), [v3-5](), [v3-5-33](), [wal](), [watch]() ### AI overview This article explains how etcd v3.5.33 embeds a single Raft group, separates EtcdServer responsibilities from the Raft library, and routes requests across Leader, Follower, and Learner roles. It covers gRPC write forwarding, linearizable and serializable reads, and the handling of watch, lease, and mutating requests. ### Source excerpt 钉清 etcd v3.5.33 单 Raft 组拓扑、EtcdServer 与 go.etcd.io/raft/v3 边界、Leader/Follower/Learner 角色及 gRPC 写读路由；与 distributed/13 分工。 ## Data Engineering Weekly #282 DevFeed: [Data Engineering Weekly #282]() Original publisher: [Read original article]() Author: Ananth Packkildurai Published: 2026-08-10T01:21:26Z Content type: article Language: en Sources: [Data Engineering Weekly]() Topics: [data-engineering](), [data-platforms](), [data observability](), [Graphs](), [semantic-layer](), [Large Language Model](), [Apache Iceberg](), [gRPC](), [Concurrency](), [Caching](), [Optimization](), [Streaming]() Tags: [caching](), [chaos](), [concurrency](), [data](), [data-engineering](), [data-platforms](), [data-quality](), [knowledge-graphs](), [llms](), [newsletter](), [observability](), [pipelines](), [semantic-layer](), [streaming]() ### AI overview Data Engineering Weekly #282 is a newsletter covering data platform fundamentals, semantic layers, ontology-backed knowledge graphs, converged databases, AI modernization, and Netflix's real-time distributed graph query architecture. It highlights composable architectures, data quality and observability, evolving schemas supported by LLM-assisted extraction, Iceberg full-text search, and optimization techniques including concurrency control, streaming filters, and caching. ### Source excerpt The Weekly Data Engineering Newsletter ## How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC... DevFeed: [How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC...]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-08-07T16:01:02Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [Graphs](), [gRPC](), [Netflix](), [real-time](), [Latency](), [API](), [Streaming](), [personalization](), [Security](), [apache-flink]() Tags: [apache](), [apache-flink](), [api](), [data](), [data-processing](), [events](), [latency](), [netflix](), [personalization](), [real-time](), [security](), [streaming]() ### AI overview Netflix's third-part blog post describes the serving layer for its Real-Time Distributed Graph and explains how gRPC enables efficient graph querying. It focuses on serving diverse workloads, including security lookups and personalization traces, with sub-100ms responses across a billion-edge graph. ### Source excerpt How and Why Netflix Built a Real-Time Distributed Graph: Part 3 -- Querying the graph with gRPC execution API Authors: Nilesh Mishra and Ajit Koti This is the third entry of a multi-part blog series describing how we built a Real-Time Distributed Graph (RDG). In Part 1, we discussed the motivation for creating the RDG and the architecture of the data processing pipeline that populates it. In Part 2, we discussed how we designed the storage layer to handle billions of nodes and edges while maintaining single-digit-millisecond latency. In Part 3, we will explore how we designed a fast, flexible serving layer to efficiently query the graph. Introduction In Part 1 of this series, we described why Netflix needed a Real-Time Distributed Graph (RDG) and how we used Apache Flink to build an ingestion and processing pipeline that turns streaming events into graph primitives. In Part 2, we explored how we designed a storage layer capable of handling billions of nodes and edges while still delivering single-digit-millisecond latency. In this post, we focus on the next challenge: querying the graph efficiently to power real-time insights for our internal partners. All of the work on ingestion and storage only matters if we can actually ask complex questions and get answers back quickly. As we optimized for lower latency, we found that the serving layer posed its own set of challenges, distinct from those of ingestion and storage. How do we turn a constantly evolving, billion-edge graph into sub-100ms responses across a wide variety of workloads? This is the problem we tackle in this post. The Real World Needs As we integrated the RDG into Netflix's ecosystem, we realized that "querying the graph" is not a one-size-fits-all operation. We needed to handle a wide range of access patterns: from high-volume security lookups to deep, exploratory personalization traces. Let's revisit our example from Part 1 and expand on it slightly. In the earlier posts, we focused on accounts, device ## In-House LLM Serving at Netflix DevFeed: [In-House LLM Serving at Netflix]() Original publisher: [Read original article]() Author: Netflix Technology Blog Published: 2026-07-17T21:32:39Z Content type: article Language: en Sources: [Netflix](), [Netflix TechBlog - Medium]() Topics: [LLMs](), [Netflix](), [Inference](), [AI Platform](), [model-deployment](), [autoscaling](), [GPU](), [gRPC]() Tags: [ai](), [ai-platform](), [autoscaling](), [deployment](), [gpu](), [inference](), [llm](), [model-serving](), [netflix](), [platform-engineering]() ### AI overview Netflix describes its in-house LLM serving stack, covering deployment, inference, API access paths, and production trade-offs. ### Source excerpt By AI Platform's Model Runtime team and Inference team Introduction Most organizations consume LLMs through hosted APIs. Netflix went further -- we run the full stack ourselves, from model deployment through inference, inside our existing production environment rather than a separate ML silo. Some of those decisions weren't obvious, and a few revealed their trade-offs only under production load. This post focuses on the choices where alternatives were seriously considered: engine selection, model packaging, API surface design, deployment strategy, and output constraints enforcement. The goal is to share not just what was built, but why -- and what production revealed that the design phase didn't anticipate. Architecture Overview Member-scale ML at Netflix is fronted by a unified JVM-based serving system that handles the end-to-end flow for downstream consumers: routing and A/B test logic, candidate generation, feature fetching, inference, post-processing, and logging at each stage. Both real-time and cached batch paths are supported. Figure 1 shows the two ways callers reach inference today: the gRPC path through this serving system and a direct HTTP path used by newer LLM-driven applications. Where inference runs depends on the model. Small CPU models run in-process, avoiding remote-call overhead. Larger models need GPUs -- the serving system handles pre- and post-processing locally but delegates inference to a remote service, Model Scoring Service (MSS). MSS is the shared inference backend, supporting XGBoost, TensorFlow, PyTorch, and LLMs behind a unified interface, with NVIDIA Triton Inference Server underneath managing model loading, batching, and GPU scheduling. On top of Triton sits a Java control plane that handles deployment, versioning, health checking, autoscaling, and multi-region rollout. Model authors package their artifacts and configure the deployment; the control plane provisions GPU instances, configures Triton, and orchestrates zero-downtime upgrades ## Scale Faster with Managed Weaviate: Now in Public Preview on DigitalOcean DevFeed: [Scale Faster with Managed Weaviate: Now in Public Preview on DigitalOcean]() Original publisher: [Read original article]() Author: Waverly Swinton Published: 2026-07-09T19:08:52Z Content type: release Language: en Sources: [DigitalOcean]() Topics: [Digital Ocean](), [Cloud](), [Databases](), [Retrieval Augmented Generation (RAG)](), [autoscaling](), [Self-hosted](), [GraphQL](), [gRPC]() Tags: [autoscaling](), [configuration](), [database](), [databases](), [digitalocean](), [graphql](), [high-availability](), [hosting](), [infrastructure](), [preview](), [product-updates](), [real-time](), [rest](), [retrieval](), [run](), [security](), [storage](), [upgrades](), [workflows]() ### AI overview DigitalOcean has placed Managed Weaviate into public preview. The service provides fully managed Weaviate clusters with automated backups, security patching, version upgrades, high availability, and storage autoscaling, with pricing starting at $20 per month. ### Source excerpt Production Weaviate in minutes, managed by DigitalOcean. Starting at $20/month. Vector databases have become a core piece of the AI application stack. Whether you're building retrieval-augmented generation (RAG), semantic search, agentic workflows and memory, or similarity-based recommendations, you need a vector store that's reliable, fast, and doesn't require a dedicated ops engineer to keep running. Weaviate has become a critical part of that stack -- its open-source AI-native vector database powers semantic search, RAG, and agentic workflows for thousands of companies. Self-hosting Weaviate is doable but it comes at a cost. You're on the hook for backups, version upgrades, security patches, high availability configuration, and storage scaling. That's real time and real engineering capacity that isn't going toward your product. Managed alternatives from larger cloud vendors exist, but they often come with per-query fees, per-dimension surcharges, and pricing models that are difficult to predict as usage grows. Today, we're announcing that Managed Weaviate is now in public preview on DigitalOcean, offering an easy way for you to run Weaviate in production, at a price that makes sense from day one. The easiest way to run Weaviate in production Managed Weaviate on DigitalOcean handles the operational work so you don't have to. Provision a fully managed Weaviate cluster directly from the DigitalOcean control panel. From there, automated backups, security patching, version upgrades, high availability, and storage autoscaling are handled for you. Full Weaviate client compatibility via GraphQL, REST, and gRPC on port 443 means your existing code works without modification. This means you get Weaviate's full capabilities -- semantic and hybrid search, RAG pipelines, and support for agent-driven workflows -- without spending engineering time on the infrastructure beneath them. Predictable pricing, starting at $20/month We built Managed Weaviate with flat, predictable monthly ## WWDC 2026 Viewing Guide DevFeed: [WWDC 2026 Viewing Guide]() Original publisher: [Read original article]() Author: Keith Harrison Published: 2026-06-15T09:16:45Z Content type: tutorial Language: en Sources: [K. Harrison]() Topics: [Swift](), [SwiftUI](), [Xcode](), [WebAssembly](), [gRPC](), [MLX](), [NumPy](), [Testing]() Tags: [2026](), [apple](), [auto-layout](), [comparison](), [ios](), [ios27](), [macos27](), [objective-c](), [swift](), [swiftui](), [webassembly](), [wwdc](), [xcode]() ### AI overview A guide to planning and watching WWDC 2026 sessions, highlighting platform themes and selected updates in Swift, SwiftUI, Xcode, WebAssembly, gRPC, and MLX. ### Source excerpt My WWDC 2026 viewing guide to help you plan the sessions you want to watch. Where Do I Start? The two big themes for the year are again Liquid Glass and Apple Intelligence. Start by watching the Platforms State of the Union (SOTU) for a summary of what's new this year. If you only have five minutes try the SOTU recap. You don't have to learn everything new today! There are over 100 sessions and a lot of new stuff to learn. You may feel like you're getting left behind. Don't let it overwhelm you. You've got time. Don't burn yourself out trying to keep up. Watching The Sessions I watch the videos using the Apple Developer app. It's available on macOS and iOS. The video player supports from 0.5x to 2x playback, most videos have transcripts and summaries, and allow copying of the onscreen sample code. You can also watch on YouTube. There are a lot of sessions, but many are short (15-20 minutes). There's no padding and Apple's engineers get to the point quickly. Swift Swift 6.4 is here with some quality of life improvements: What's new in Swift Condense long @available attributes with anyAppleOS, @diagnose to control compiler deprecation warnings. Double-colon module selector. Standard Library task cancellation shield, dictionary mapKeyedValues, new FilePath type. XCTest interop with Swift Testing. Subprocess 1.0. New ProgressManager. @C attribute for Swift-C interop. Compile to WebAssembly. New @inline(always) and @specialized attributes. Iterable protocol for noncopyable elements. Build real-time apps and services with gRPC and Swift gRPC Swift package to generate and deploy network code for remote procedure call services. Explore numerical computing in Swift with MLX NumPy-like API. Examples of computing the Mandlebrot set, heat distribution, and curve fitting. SwiftUI Liquid Glass changes and some welcome improvements: What's new in SwiftUI Liquid Glass is now mandatory. Minimal menu icons by default. Resize live previews in Xcode. Prominent tab role. Toolbar visibil ## WebSockets, gRPC, And GraphQL In The Core DevFeed: [WebSockets, gRPC, And GraphQL In The Core]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-07T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [WebSocket](), [GraphQL](), [gRPC](), [real-time](), [API](), [Code generation]() Tags: [api](), [graphql](), [pipeline](), [real-time](), [tutorial](), [websocket]() ### AI overview A hands-on tutorial covering WebSockets, typed GraphQL clients, and typed gRPC clients in the core framework. It explains how to build a real-time chat, generate typed clients from GraphQL schemas and proto files, and use WebSocket subscriptions. ### Source excerpt A hands-on walk through the three connectivity features that landed together this week, building a live chat over the new core WebSocket API and typed clients from a GraphQL schema and a proto file. ## Mac Native Builds, Live Protocols, And Open Issues Under 350 DevFeed: [Mac Native Builds, Live Protocols, And Open Issues Under 350]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-05T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [WebSocket](), [GraphQL](), [gRPC](), [issue tracker](), [API](), [Feathers](), [Java]() Tags: [api](), [electron](), [framework](), [integration](), [issue](), [mac]() ### AI overview Codename One reports that its open issue count fell to 332 after reviewing older tracker reports. The weekly update also covers native Mac builds, WebSockets in the core framework, gRPC and GraphQL integration, a new advertising API, and richer background work. ### Source excerpt The open issue count dropped below 350 after a push through the oldest reports, and the same week brought native Mac builds, WebSockets in the core, gRPC and GraphQL integration, a new advertising API, and richer background work. ## Logging, Metrics, and Distributed Tracing in .NET with OpenTelemetry and ClickStack DevFeed: [Logging, Metrics, and Distributed Tracing in .NET with OpenTelemetry and ClickStack]() Original publisher: [Read original article]() Author: Alex Soffronow Pagonidis Published: 2026-06-03T09:21:38Z Content type: tutorial Language: en Sources: [ClickHouse Blog]() Topics: [ASP.NET](), [OpenTelemetry](), [tracing](), [Grafana](), [telemetry](), [Instrumentation](), [SQLite](), [API](), [gRPC](), [SQL]() Tags: [api](), [instrumentation](), [logging](), [metrics](), [observability](), [opentelemetry](), [sql](), [sqlite](), [traces](), [tracing]() ### AI overview A practical walkthrough of instrumenting two ASP.NET services with OpenTelemetry and sending traces, logs, and metrics to ClickStack. The example uses an Order API and a Payment Service, with SQLite persistence and cross-service trace correlation. ### Source excerpt A walkthrough of adding OpenTelemetry instrumentation to two ASP.NET services -- an Order API and a Payment Service -- and shipping traces, logs, and metrics to ClickStack, with auto-correlated signals and cross-service trace waterfalls out of the box. ## REST vs GraphQL vs gRPC DevFeed: [REST vs GraphQL vs gRPC]() Original publisher: [Read original article]() Author: Nikki Siapno Published: 2026-05-28T10:32:52Z Content type: comparison Language: en Sources: [Level Up Coding System Design Newsletter]() Topics: [API](), [GraphQL](), [gRPC](), [HTTP](), [JSON]() Tags: [apis](), [graphql](), [http](), [json](), [rest]() ### AI overview A comparison of REST, GraphQL, and gRPC explains how each API style organizes communication and the tradeoffs each makes between flexibility, simplicity, efficiency, and control. ### Source excerpt The tradeoffs behind resource-driven, query-driven, and method-driven APIs. ## Kubelet Metrics: How cAdvisor and CRI Collect Kubernetes Stats DevFeed: [Kubelet Metrics: How cAdvisor and CRI Collect Kubernetes Stats]() Original publisher: [Read original article]() Author: Gulcan Topcu Published: 2026-05-18T00:00:00Z Content type: tutorial Language: en Sources: [Learnk8s]() Topics: [Kubernetes](), [container](), [telemetry](), [gRPC](), [Kernel]() Tags: [api](), [api-server](), [cgroups](), [collect](), [container](), [cpu](), [data](), [deployment](), [grafana](), [kernel](), [kubernetes](), [linux](), [metrics](), [monitoring](), [performance](), [pipeline](), [prometheus](), [trace](), [visibility]() ### AI overview This tutorial explains how Kubernetes collects and exposes container, pod, and node metrics through kubelet, cAdvisor, the Linux kernel, and the Container Runtime Interface (CRI). It describes the shift toward CRI-native metrics over gRPC and how Prometheus, Grafana, and other observability systems consume the data. ### Source excerpt Learn how kubelet collects Kubernetes metrics from cgroups, cAdvisor, containerd and CRI, and when pod and container stats move to the runtime. ## Announcing Microsoft Desired State Configuration v3.2.0 DevFeed: [Announcing Microsoft Desired State Configuration v3.2.0]() Original publisher: [Read original article]() Author: Jason Helmick Published: 2026-04-29T18:31:13Z Content type: release Language: en Sources: [PowerShell Team]() Topics: [PowerShell DSC](), [configuration](), [Windows](), [gRPC](), [Firewall](), [ssh]() Tags: [announcement](), [firewall](), [integration](), [microsoft](), [powershell](), [powershell-dsc](), [release](), [ssh](), [windows]() ### AI overview This Microsoft PowerShell Team post announces the general availability of Desired State Configuration (DSC) v3.2.0. The release adds built-in Windows resources, experimental Bicep integration through gRPC, extended WhatIf support, version pinning, expression language improvements, custom functions, and adapter enhancements. ### Source excerpt This post announces the General Availability of Microsoft Desired State Configuration (DSC) v3.2.0, with new Windows resources, Bicep gRPC integration, WhatIf support, expression language improvements, and adapter enhancements. The post Announcing Microsoft Desired State Configuration v3.2.0 appeared first on PowerShell Team. ## 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. ## Distributed privilege access with Temporal DevFeed: [Distributed privilege access with Temporal]() Original publisher: [Read original article]() Author: Mark Regensberg Published: 2026-02-24T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [Workers](), [systems](), [Amazon Web Services](), [Orchestration](), [gRPC](), [Open Source](), [JSON](), [YAML]() Tags: [architecture](), [aws](), [declarative](), [development](), [distributed](), [documentation](), [grpc](), [how-to](), [json](), [open-source](), [orchestration](), [workflows]() ### AI overview This article explains how Temporal can support distributed privilege access by reliably orchestrating access grants, revocations, and resource provisioning across services. It discusses distributed execution through Workers and Nexus, then combines Temporal with the CNCF Serverless Workflows specification, using YAML or JSON to define workflows that can be deployed or changed without modifying the underlying Temporal Workflow code. ### Source excerpt Discover how to solve distributed privilege access using Temporal, Serverless Workflows, and Thand. Build reliable, declarative, and secure access systems. ## Osprey: Open Sourcing our Rule Engine DevFeed: [Osprey: Open Sourcing our Rule Engine]() Original publisher: [Read original article]() Author: Discord Engineering Published: 2026-02-19T00:00:00Z Content type: article Language: en Sources: [Discord Blog]() Topics: [Discord](), [Open Source](), [real-time](), [gRPC](), [Standard ML]() Tags: [customers](), [debugging](), [discord](), [open-source](), [real-time](), [tool]() ### AI overview Discord introduces Osprey, an open-source safety rules engine developed with ROOST and the internet.dev team. It processes real-time platform activity through expressive SML rules, supports synchronous gRPC and asynchronous message-queue inputs, and produces transparent verdicts and investigation data. ### Source excerpt Discord uses Osprey to quickly detect and remove new types of harm from putting our customers at risk. Now we're open-sourcing this tool so others can do the same. ## Laravel November Product Releases DevFeed: [Laravel November Product Releases]() Original publisher: [Read original article]() Author: Laravel Team Published: 2025-12-02T16:20:46Z Content type: article Language: en Sources: [Laravel Blog]() Topics: [Laravel](), [releases](), [Cloud](), [WebSocket](), [real-time](), [Provisioning](), [PostgreSQL](), [Amazon Web Services](), [gRPC](), [SSL](), [MFA](), [PHP]() Tags: [apis](), [authentication](), [availability](), [aws](), [caching](), [changelog](), [cloud](), [collaboration](), [laravel](), [monitoring](), [open-source](), [performance](), [php](), [postgresql](), [product-updates](), [provisioning](), [real-time](), [releases](), [ssl](), [updates]() ### AI overview Laravel's November product releases cover generally available Laravel Reverb-powered WebSockets in Laravel Cloud, a developer preview of Laravel Valkey, a new Canada region, gRPC PHP extension support, and Laravel Forge improvements for AWS EBS gp3 provisioning, PostgreSQL 18, and SSL certificate management. Laravel Nightwatch also received rewritten documentation and richer log context, while Laravel 12.x added several framework improvements. ### Source excerpt Laravel's November product updates for Laravel Cloud, Forge, Nightwatch, and Laravel 12.x. ## How Block Scaled Graph Adoption with Apollo and AI DevFeed: [How Block Scaled Graph Adoption with Apollo and AI]() Original publisher: [Read original article]() Author: Valeria Gomez Published: 2025-11-24T12:30:00Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Apollo Connectors](), [Model Context Protocol](), [AI Agent](), [gRPC](), [API](), [Tooling]() Tags: [ai-agent](), [apollo-connectors](), [events](), [graphql](), [learn](), [mcp](), [rest-apis](), [services](), [software]() ### AI overview The article recaps Block's GraphQL Summit 2025 session on scaling graph adoption. Block used Apollo Connectors to bring gRPC services onto a federated graph through their existing JSON translation layer, then combined Apollo MCP Server with its open-source AI agent Goose to generate Connector schemas, directives, types, and tests. ### Source excerpt A recap from Block's GraphQL Summit 2025 session on scaling graph adoption with Apollo Connectors, Apollo MCP, and AI When Block's GraphQL platform team discovered Apollo Connectors, they saw a path to bring thousands of existing APIs onto the graph without asking hundreds of engineering teams to run new services or learn new tooling. ## Introducing wasi-grpc for Spin DevFeed: [Introducing wasi-grpc for Spin]() Original publisher: [Read original article]() Author: Brian Hardock Published: 2025-09-08T12:00:00Z Content type: release Language: en Sources: [Fermyon - Experience the next wave of cloud computing.]() Topics: [gRPC](), [Cloud Native Ecosystem](), [Cloud APIs]() Tags: [2](), [apis](), [components](), [http](), [service](), [wasi]() ### AI overview Spin 3.4 adds outbound HTTP/2 support, allowing components to function as gRPC clients and enabling Spin applications to connect directly to existing gRPC systems, cloud APIs, and service meshes. ### Source excerpt Spin 3.4 introduces outbound HTTP/2 support, enabling components to act as first-class gRPC clients. Spin applications can now call into existing gRPC-based systems, cloud APIs, and service meshes directly, without workarounds. ## Introducing multi-language dynamic plugins for Redpanda Connect DevFeed: [Introducing multi-language dynamic plugins for Redpanda Connect]() Original publisher: [Read original article]() Author: James Kinley Published: 2025-06-17T00:00:00Z Content type: release Language: en Sources: [Redpanda]() Topics: [gRPC](), [SDKs](), [Go Language](), [Python](), [Processes](), [streaming-data-processing](), [Unix]() Tags: [ai-ml-capabilities-in-streaming-data](), [architecture](), [configuration](), [creating-plugins-in-golang-and-python](), [dynamic-vs-compiled-plugins](), [framework](), [go](), [grpc-plugin-system](), [integration](), [interfaces](), [ipc](), [language-agnostic-plugin-system](), [multi-language-plugin-development](), [pipelines](), [plugin-development](), [plugins](), [process](), [processes](), [product](), [protocol](), [python](), [python-sdk-for-streaming-data](), [redpanda-connect](), [redpanda-connect-dynamic-plugins](), [redpanda-streaming-infrastructure](), [runtime-loaded-plugins-grpc](), [sdk](), [sdks](), [stream-processing](), [streaming-data-pipeline-plugins]() ### AI overview Redpanda Connect introduces Apache 2.0-licensed dynamic plugins in Beta with version 4.56.0. Plugins can be loaded at runtime as external executables that communicate with the main process through gRPC over Unix sockets, enabling plugin development in Go and Python. Official SDKs support both languages, while native Go plugins remain the preferred option for performance-critical workloads. ### Source excerpt Redpanda Connect dynamic plugins framework allows you to create and load plugins at runtime, opening up a world of new integration possibilities beyond Go. [Next page]()