# client library Published articles for client library. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Using the GitHub Copilot SDK for Java DevFeed: [Using the GitHub Copilot SDK for Java]() Original publisher: [Read original article]() Author: Edward Burns Published: 2026-08-10T19:30:00Z Content type: tutorial Language: en Sources: [GitHub]() Topics: [GitHub Copilot](), [Java](), [SDK](), [Jakarta EE](), [Agent Harness](), [Artificial Intelligence](), [Command-line interface](), [Spring AI]() Tags: [agent](), [agent-harness](), [ai](), [ai-ml](), [cli](), [client-library](), [engineering](), [framework](), [github-copilot](), [github-copilot-sdk](), [jakarta-ee](), [java](), [sdk]() ### AI overview This tutorial introduces the GitHub Copilot SDK for Java, a framework-agnostic client library for creating Copilot agent sessions, registering tools, sending prompts, and receiving structured responses. It demonstrates the SDK in a Jakarta EE 11 real-estate lead-management application and describes prerequisites including JDK, Maven, a GitHub Copilot subscription, and the Copilot CLI. ### Source excerpt Enterprise Java developers have a new superpower--drive GitHub Copilot from idiomatic Java code with annotations, virtual threads, and more. The post Using the GitHub Copilot SDK for Java appeared first on The GitHub Blog. ## The New Apollo Kotlin Normalized Cache DevFeed: [The New Apollo Kotlin Normalized Cache]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2026-03-09T01:00:13Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [Caching](), [Kotlin](), [Android](), [client library](), [GraphQL](), [Library]() Tags: [android](), [announcement](), [caching](), [client-library](), [graphql](), [kotlin](), [library](), [versioning]() ### AI overview Apollo released version 1 of a new normalized cache library for Apollo Kotlin, the GraphQL client library for Android and Kotlin. It adds pagination support, expiration, partial cache reads, garbage collection and trimming, configurable key scopes, and improved SQL cache performance. ### Source excerpt Today, we're releasing the new cache library for Apollo Kotlin, the GraphQL client library for Android and Kotlin. Historically, caching has generated the most questions, tickets, and feedback, and we knew it was an area that deserved significant attention. To do that efficiently, we decided early on to create a new repository with its own independent name, artifacts, and versioning. This allowed us to iterate on this new version without disrupting the existing stable library. ## Dart Client for Genkit DevFeed: [Dart Client for Genkit]() Original publisher: [Read original article]() Author: Nozomi Koborinai Published: 2025-10-23T10:49:27Z Content type: tutorial Language: en Sources: [Firebase Developers - Medium]() Topics: [Genkit](), [Dart](), [client library](), [Flutter](), [AI Development](), [Cloud Functions](), [Cloud Run]() Tags: [ai-development](), [apis](), [client-library](), [dart](), [firebase](), [flutter](), [genkit](), [google-cloud-platform](), [http](), [open-source](), [server-sent-events-sse](), [streaming]() ### AI overview This article introduces a Dart client library for calling Genkit flows deployed on a server from Flutter or other Dart applications. It explains that the library handles Genkit request and response conventions, reduces repeated HTTP client code, supports authentication mechanisms, and simplifies streaming responses through Server-Sent Events. The client can call flows implemented with Genkit JS, TypeScript, or Go when their server endpoints are accessible. ### Source excerpt Introducing the Dart Client for GenkitCalling Genkit Flows from Flutter/DartDart client for Genkit I'm a big fan of Firebase and often choose Flutter as my front-end framework. Since Google I/O 2024, I've been continuously exploring Genkit. Developed by the Firebase team, Genkit is an open-source framework from Google that simplifies the definition of AI-powered processing sequences on the server-side as Flows. Genkit | Open-source AI development framework by Google However, calling a server-defined flow from a Dart/Flutter client application required some extra effort. To bridge this gap, I developed the Dart client for Genkit package. genkit | Dart package Note: This library is not for defining Genkit flows themselves. It is specifically designed for easily and securely calling flows deployed on a server from a Dart client.Library overview As mentioned above, this library is a dedicated client for easily calling Genkit flows deployed on a server (e.g., as Web APIs on platforms like Cloud Functions for Firebase, Cloud Run, or GKE). It is not for implementing Genkit flows in Dart. The challenges before Previously, calling a Genkit flow from Dart/Flutter required manually implementing an HTTP client according to a set of conventions. For example, here's a typical piece of code using the dio package to call an image generation flow defined in Genkit. Future generateImage({required String imageDescription}) async { try { final response = await dio.post( 'https:///generateImage', data: { 'data': { 'imageDescription': imageDescription, }, }, ); if (response.statusCode == 200) { return response.data['result']['url'] as String; } throw Exception('Failed to generate image: ${response.statusCode}'); } on DioException catch (e) { throw Exception('Failed to generate image: ${e.message}'); } } This code presents several challenges: When sending a request, the input must be wrapped in {'data': ...}, and when receiving a response, the result must be ex ## Backwards compatibility in Keycloak releases DevFeed: [Backwards compatibility in Keycloak releases]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2024-10-08T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [releases](), [version](), [client library](), [API](), [deprecated]() Tags: [api](), [client-library](), [compatibility](), [deprecated](), [idm](), [kerberos](), [keycloak](), [ldap](), [openid-connect](), [releases](), [saml](), [sso](), [version]() ### AI overview Keycloak announces changes to its release model after version 26.0. The server will receive four minor releases each year and a major release every two to three years, while client libraries will be released separately and support all currently supported server releases. ### Source excerpt With four major releases of Keycloak every year it can be a daunting task to keep deployments up to date. Especially, since the number of breaking changes have drastically increased the last couple years. Combine this with the importance of patching deployments quickly for vulnerabilities, this can leave many deployments open to known vulnerabilities as the time and effort required to update to the latest release is too costly. Additionally, currently Keycloak client libraries are released together with the server, resulting in new major versions of a client library, where in fact there can be no changes at all, or perhaps only a bug fix or two. For these reasons, after Keycloak 26.0 is released there will be some changes to how Keycloak is being released: Keycloak server will have 4 minor releases every year, and a major release every 2-3 years Keycloak client libraries will be released separately. The latest client library release will support all currently supported Keycloak server releases We will continue to bring new features and enhancements to Keycloak in each release, and we are committed to doing so in a backwards compatible way, making it seamless and easy to upgrade. When a minor comes with breaking changes, such changes will be opt-in. This will be driven through versioning where the currently default version for a Feature or an API can not change in a minor release, and there will be a new version that can be explicitly enabled. The current version of a Feature or API can be deprecated in a minor, but will not be removed until the next major version. This will allow you to gradually roll-out new Feature or API versions separately from upgrading. You can choose to get ready for the next major release early, or wait and do it in one go. Backwards compatibility guarantees will only be given to Features and APIs that are fully supported. Preview features or preview APIs, as well as non-public APIs may change at any time. ## Announcing Supabase on JSR DevFeed: [Announcing Supabase on JSR]() Original publisher: [Read original article]() Author: Bobbie Soedirgo; Thor Schaeff Published: 2024-07-16T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Supabase](), [JavaScript](), [TypeScript](), [Deno](), [Authentication](), [Web]() Tags: [announce](), [announcement](), [authentication](), [client-library](), [database](), [dependencies](), [developer](), [developer-experience](), [documentation](), [import](), [javascript](), [npm](), [open-source](), [other](), [provenance](), [published](), [real-time](), [registry](), [source](), [storage]() ### AI overview Supabase announces that its JavaScript client library is available on JSR, an open source JavaScript registry. The article describes JSR support for TypeScript source publishing, generated documentation and type definitions, provenance attestation, and npm-like package managers, then outlines installation and use of the client across JavaScript environments. ### Source excerpt Supabase is now available on the open source JavaScript Registry (JSR). ## Getting Started with Socket.IO: Building Real-Time Web Applications DevFeed: [Getting Started with Socket.IO: Building Real-Time Web Applications]() Original publisher: [Read original article]() Author: Jitendra Kumar Published: 2024-06-12T06:49:56Z Content type: tutorial Language: en Sources: [Housing.com]() Topics: [Socket.IO](), [WebSocket](), [Node.js](), [HTTP](), [servers]() Tags: [client-library](), [event](), [http](), [latency](), [node-js](), [real-time](), [server](), [web-applications](), [websocket]() ### AI overview This tutorial introduces Socket.IO as a Node.js server-side library for low-latency, bidirectional, event-based communication. It explains the client-server connection process, including the HTTP handshake, transport selection, optional upgrade to WebSocket, real-time messaging, and heartbeat keep-alive. ### Source excerpt What is Socket.io ? Socket.IO is a server-side library for nodejs that enables low-latency, bidirectional and event-based communication between a client and a server using client-server architecture while it is a wrapper around WebSockets For Node.js, it is super easy and simple to use especially when dealing with chat messages or Real-time data. Socket Client-Server Architecture How persistent bi-directional connection is established between client(s) and server ? The connection process between a Socket.IO client and server involves several steps. Below is a detailed breakdown of the key steps: 1. Handshake Initialization: The client initiates a connection to the Socket.IO server by sending an HTTP request (often a GET request) to the server using constructor provided by socket-io.client library. // Connect to the server (URL is optional if both client and server are at same origin ) const socket = io('http://localhost:3000'); The request includes a specific path, typically /socket.io/, and it may also include query parameters indicating the supported Socket.IO protocol version (EIO=3), transports, and other details. Example : GET /socket.io/?EIO=3&transport=polling&t=timestamp 2. Server Handshake Response: The Socket.IO server receives the initial HTTP request and responds with a handshake. The response includes the selected transport mechanism and a unique session ID (sid) that will be used to identify the connection. 3. Connection Upgrade (Optional): If the client and server both support WebSocket and agree to use it, they may negotiate to upgrade the connection from HTTP to WebSocket. This is an optimization for more efficient and bidirectional communication. 4. Transport Initialization: Based on the handshake response, the client initializes the chosen transport (e.g., WebSocket, polling). If using WebSocket, a WebSocket connection is established directly. If using polling, the client may start polling the server for updates. 5. Real-Time Communication: Once t ## Teleport OSS will relicense to AGPLv3 DevFeed: [Teleport OSS will relicense to AGPLv3]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Alexander Klizhentas) Published: 2023-12-01T00:00:00Z Content type: release Language: en Sources: [Teleport]() Topics: [Open Source](), [Software](), [Code](), [client library]() Tags: [apache](), [binaries](), [change](), [client-library](), [container](), [open-source](), [oss](), [software](), [software-license]() ### AI overview Teleport announced that its core repository source code would switch from the Apache 2.0 license to AGPLv3 on December 1, 2023. Documentation, company-compiled OSS binaries, and client libraries would remain under Apache 2.0, while enterprise binaries would continue under a commercial license. ### Source excerpt A detailed explanation, schedule, and FAQ on why we have switched Teleport OSS to AGPLv3 software license. ## Supabase Vecs: a vector client for Postgres DevFeed: [Supabase Vecs: a vector client for Postgres]() Original publisher: [Read original article]() Author: Oliver Rice Published: 2023-05-29T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Supabase](), [Embeddings](), [PostgreSQL](), [Python](), [SQL](), [API]() Tags: [api](), [client-library](), [embeddings](), [front-end](), [postgresql](), [python](), [sql](), [vector]() ### AI overview Supabase Vecs is a Python library for managing embeddings in PostgreSQL databases that use the pgvector extension. It provides APIs for creating and indexing tables, inserting and updating records, querying vectors by distance, filtering metadata, and exposing collections to applications through database views and the Supabase client library. ### Source excerpt Introducing Supabase Vecs, a PostgreSQL vector client ## Nullability in GraphQL and Apollo Kotlin DevFeed: [Nullability in GraphQL and Apollo Kotlin]() Original publisher: [Read original article]() Author: Benoit Lubek Published: 2023-02-27T08:10:00Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Kotlin](), [client library](), [Code generation](), [Error Handling]() Tags: [apollo](), [client-library](), [error-handling](), [graphql](), [kotlin](), [mobile](), [null-safety](), [polymorphism]() ### AI overview This tutorial explains how Apollo Kotlin represents GraphQL nullability in generated Kotlin models. It covers nullable schema fields, conditional directives, fragments, polymorphism, and GraphQL partial responses caused by errors. ### Source excerpt The concept of is sometimes called a "billion dollar mistake". Mistake or not, is here to stay and there are ways to coexist peacefully! In fact, nullability is one of the key features of GraphQL, allowing API authors to clearly specify which fields of a type are nullable. As for Kotlin, the language supports nullability in its type system, significantly reducing the risk for errors - for example assigning a potentially value to a non-nullable field won't even compile! ## Diving into Mosaic for Jetpack Compose DevFeed: [Diving into Mosaic for Jetpack Compose]() Original publisher: [Read original article]() Author: Jorge Castillo Published: 2022-04-26T12:00:00Z Content type: tutorial Language: en Sources: [👨💻 Jorge Castillo]() Topics: [Compose](), [Jetpack Compose](), [client library](), [Compiler](), [ui]() Tags: [client-library](), [compiler](), [compose](), [how-to](), [implementation](), [jetpack-compose](), [library](), [ui]() ### AI overview This article explains how Mosaic, a console UI library, uses the Jetpack Compose compiler and runtime. It covers composables, state and recomposition, and the nodes and applier implementation used to build, measure, lay out, and render console UI. ### Source excerpt Overview on how to create a client library for the Compose compiler and runtime. ## WorkManager for Background Work in Libraries DevFeed: [WorkManager for Background Work in Libraries]() Original publisher: [Read original article]() Author: Stephen Edwards Published: 2021-07-21T19:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [Mobile](), [Library](), [Logging](), [Code](), [SDK]() Tags: [android](), [client-library](), [engineering](), [library](), [logging](), [mobile](), [sdk]() ### AI overview This article explains the challenge of using Android Jetpack WorkManager from libraries that need reliable, deferrable background work. It focuses on the difficulty of sharing WorkManager's singleton when libraries have custom worker dependencies, especially for logging clients and SDKs. ### Source excerpt Making it easy on applications by cleanly sharing the Singleton ## Introducing the Apollo Client Best Practices Series DevFeed: [Introducing the Apollo Client Best Practices Series]() Original publisher: [Read original article]() Author: Khalil Stemmler Published: 2020-07-17T10:56:17Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [GraphQL](), [client library](), [Developer experience]() Tags: [apollo](), [apollo-client](), [best-practices](), [client-library](), [developer-experience](), [graphql](), [guide](), [series]() ### AI overview Apollo introduces a best-practices series for Apollo Client, a GraphQL client library that also supports client-side caching, state management, and data fetching. The series covers architecture, state types, testing, pagination, server-side rendering, security, and building testable, flexible, maintainable production applications. ### Source excerpt If you've been entrusted to build something important, it's always good to know you have resources to rely on. Maybe a team member. Maybe a book or a course. Walking into a project with a set of new tools can be pretty scary. That's where I think best practices come in. As a part of the Developer Experience team at Apollo, and someone who personally uses Apollo's tools, I totally know what it feels like to not know if I'm doing things correctly. ## Announcing the Release of Apollo Client 3.0 DevFeed: [Announcing the Release of Apollo Client 3.0]() Original publisher: [Read original article]() Author: Ben Newman Published: 2020-07-14T12:41:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [apollo-client](), [GraphQL](), [Caching](), [Library]() Tags: [announce](), [announcement](), [apollo-client](), [caching](), [client-library](), [graphql](), [refactoring](), [release]() ### AI overview Apollo Client 3.0 is officially released after an extended beta period. The release consolidates the package, improves local state management, and includes internal refactoring. The article explains Apollo Client's cache-focused design for reconstructing a local subset of a GraphQL server's data graph. ### Source excerpt Today we're thrilled to announce the official release of Apollo Client 3.0! This release is the culmination of 55 betas, 14 release candidates, and hundreds of resolved issues and merged pull requests over the past eleven months. Phew! To everyone who's tried out AC3 during this extended beta period, thank you. We couldn't have reached this milestone without your continued feedback and support. And to everyone who's been waiting for the official launch, we appreciate your patience. ## Great Rust Libraries / Tools DevFeed: [Great Rust Libraries / Tools]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2020-02-21T00:00:00Z Content type: article Language: en Sources: [Scott Johnson]() Topics: [Rust](), [Tooling](), [client library](), [Database](), [Kafka](), [Erlang]() Tags: [client-library](), [database](), [distributed](), [embedded](), [high-performance](), [kafka](), [libraries](), [ruby](), [rust](), [tools]() ### AI overview The author introduces Rust after years of primarily using Ruby and describes several Rust libraries and tools, including a Reddit client, string matcher, Kafka client, filesystem watchers, an embedded database, and a distributed runtime. The article highlights Rust's performance and cites benchmark figures for Sled. ### Source excerpt I don't often do the dance with new languages. I suspect you could view my approach to languages as monogamy - I've been in a long term, monogamous relationship with Ruby now since 2007. But 12 years is a long time and deciding to dance with Python this past fall was perhaps my break through event away from "language monogamy". I'm now happily dating other languages and the latest one to turn my head is Rust. I've been very impressed with the quality of the core tooling around Rust and here are some of those tools: https://github.com/IntrepidPig/orca - Reddit client library https://github.com/BurntSushi/aho-corasick - String / Substring matcher https://crates.io/crates/kafka - Kafka client https://github.com/notify-rs/notify - Filesystem watcher; this is what drew me to using Rust; I have a high performance application where I'm virtually certain Ruby is going to fall over and die. Rust gives me an alternative. https://github.com/francesca64/hotwatch - make notify easier to use http://eradman.com/entrproject/ - A filesystem watcher built on top of Rust; possible alternative. https://github.com/watchexec/watchexec - Another filesystem watcher built on top of Rust; possible alternative. https://github.com/spacejam/sled - An embedded database built in Rust https://github.com/bastion-rs/bastion - Seemingly an Erlang like distributed runtime; fascinating AF if it is true One of the reasons you use Rust is performance and the metrics on Sled are pretty impressive: over a billion operations in under a minute at 95% read 5% writes on 16 cores on a small dataset a crash-safe monotonic ID generator capable of generating 75-125 million unique ID's per second Sources / Things to Read Getting Started with Rust Rust and Ruby Rust and Kafka Rust File Watcher Textmate 2 and Rust Rust Package Index ## An update about Redis developments in 2019 DevFeed: [An update about Redis developments in 2019]() Original publisher: [Read original article]() Published: 2019-02-20T12:14:11Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis](), [Protocol (disambiguation)](), [Caching](), [client](), [Library]() Tags: [caching](), [client-library](), [development](), [library](), [protocol](), [redis]() ### AI overview This Redis blog post responds to community concerns about Redis development in 2019. It explains that RESP3 is intended to simplify client handling and that its reply attributes support server-assisted client-side cache invalidation. ### Source excerpt Yesterday a concerned Redis user wrote the following on Hacker News: -- https://news.ycombinator.com/item?id=19204436 -- I love Redis, but I'm a bit skeptical of some of the changes that are currently in development. The respv3 protocol has some features that, while they sound neat, also could significantly complicate client library code. There's also a lot of work going into a granular acl. I can't imagine why this would be necessary, or a higher priority than other changes like multi-thread support, better persistence model, data-types, etc. -- end of user comment -- I've the feeling she/he (not sure) is not the only one that looks at ACLs as some sort of feature imposed by the Redis Labs goals, because "enterprise users" or something like that. Also the other points in the comment are interesting, and I believe everything is very well worth addressing in order to communicate clearly with the Redis community what's the road ahead. For simplicity I'll split this blog post into sections addressing every single feature mentioned in the original comment. ## RESP3 The goal of RESP3, as I already blogged in these pages, is to actually simplify the clients landscape. Hopefully every client will have a lower layer that will not try to reinvent some kind of higher level interface: redis.call("get","foo"). There is no longer need to orchestrate conversions because now the protocol is semantical enough to tell the client what a given reply should look like in the hand of the caller, nor any need to know beforehand the command fingerprint for the majority of commands. What I think the user is referring is RESP3 support for out of band communications, that is the reply "attributes". I really believe that in the future of Redis "client side caching" will be a big thing. It's the logical step in every scalable system. However without server assistance client side cache invalidation is a nightmare. This is the reason why RESP3 supports attributes in replies, mainly. However probably ## RESP3 design and backward compatibility in Redis 6 DevFeed: [RESP3 design and backward compatibility in Redis 6]() Original publisher: [Read original article]() Published: 2018-11-09T15:31:10Z Content type: opinion Language: en Sources: [Antirez]() Topics: [Redis](), [Protocol (disambiguation)](), [client library]() Tags: [client-library](), [protocol](), [redis]() ### AI overview The author discusses implementing RESP3, a more semantic client-server protocol planned for Redis 6. An edit says that enabling RESP3 per connection could address backward-compatibility concerns and changes the author's view of the original proposal. ### Source excerpt [EDIT! I'm reconsidering all this because Marc Gravell from Stack Overflow suggested that we could just switch protocol for backward compatibility per-connection, sending a command to enable RESP3. That means no longer need for a global configuration that switches the behavior of the server. Put in that way it is a lot more acceptable for me, and I'm reconsidering the essence of the blog post] A few weeks after the release of Redis 5, I'm here starting to implement RESP3, and after a few days of work it feels very well to see this finally happening. RESP3 is the new client-server protocol that Redis will use starting from Redis 6. The specification at https://github.com/antirez/resp3 should explain in clear terms how this evolution of our old protocol, RESP2, should improve the Redis ecosystem. But let's say that the most important thing is that RESP3 is more "semantic" than RESP2. For instance it has the concept of maps, sets (unordered lists of elements), attributes of the returned data, that may augment the reply with auxiliary information, and so forth. The final goal is to make new Redis clients have less work to do for us, that is, just deciding a set of fixed rules in order to convert every reply type from RESP3 to a given appropriate type of the client library programming language. In the future of Redis I see clients that are smarter under the hood, trying to do their best in order to handle connections, pipelining, and state, and apparently a lot more simpler in the user-facing side, to the point that the ideal Redis client is like: result = redis.call("GET",keyname); Of course on top of that you can build more advanced abstractions, but the bottom layer should look like that, and the returned reply should not require any filtering that is ad-hoc for specific commands: RESP3 return type should contain enough information to return an appropriate data type. So HGETALL will return a RESP3 "map", while LRANGE will return an "array", and EXISTS will return a RE ## Apollo Link: The modular GraphQL network stack DevFeed: [Apollo Link: The modular GraphQL network stack]() Original publisher: [Read original article]() Author: Evans Hauser Published: 2017-07-25T18:17:28Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [apollo-client](), [client library](), [Data Management](), [Caching]() Tags: [apollo-client](), [batching](), [caching](), [client-library](), [data-management](), [flow](), [frontend](), [graphql](), [modular]() ### AI overview The article introduces Apollo Link, a modular architecture for managing GraphQL network operations. It explains how composable Links can handle concerns such as polling, caching, retries, mutation queuing, and offline support, allowing developers to assemble a GraphQL client with the functionality they need. ### Source excerpt When we started building Apollo Client, our goal was to empower people to use GraphQL in the way they want. This goal, and countless conversations with developers using GraphQL, drives all of our design decisions. (For example, we started by integrating with Redux because that's what most React developers were familiar with.) We found that there was a core set of data management features that people needed in a GraphQL client: caching, polling, pagination, batching and a few other things. ## Anonymous Sandbox DevFeed: [Anonymous Sandbox]() Original publisher: [Read original article]() Author: Tristan Sokol Published: 2016-12-08T19:06:27Z Content type: release Language: en Sources: [Square Corner Blog RSS Feed]() Topics: [API](), [SDKs](), [client]() Tags: [api](), [apis](), [client-library](), [developers](), [documentation](), [responses](), [sandbox](), [test]() ### AI overview Square introduces Anonymous Sandbox, a persistent credentialed environment that lets developers try Square API requests and code samples without logging in, creating an account, or risking real environments. It initially supports only V2 APIs. ### Source excerpt You might have noticed that we have a new section in the sample code section of our API reference. Say hello to your new Anonymous Sandbox! ## How Long Does it Take for My Firebase Analytics Data to Show Up? DevFeed: [How Long Does it Take for My Firebase Analytics Data to Show Up?]() Original publisher: [Read original article]() Author: Todd Kerpelman Published: 2016-11-28T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Latency](), [client](), [App]() Tags: [analytics](), [app](), [apps](), [batch](), [battery](), [bigquery](), [client-library](), [console](), [firebase](), [google-analytics](), [google-play](), [ios](), [latency]() ### AI overview This Firebase team tutorial explains why Firebase Analytics data may not appear immediately. It distinguishes client-to-server latency from server-to-console latency and describes batching behavior, including timing and platform-specific conditions for sending data. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Retrofit 2.0 Samples DevFeed: [Retrofit 2.0 Samples]() Original publisher: [Read original article]() Author: Chris Hager Published: 2015-10-12T00:00:00Z Content type: tutorial Language: en Sources: [Chris Hager]() Topics: [Library](), [API](), [client library](), [Java](), [Gson](), [HTTP](), [Android](), [Gradle](), [JSON](), [GitHub]() Tags: [android](), [api](), [articles](), [client-library](), [github](), [gradle](), [gson](), [java](), [json](), [retrofit]() ### AI overview A tutorial on using Retrofit 2.0 beta to consume HTTP APIs in Java and Android applications. It covers project setup with Gradle, JSON serialization with Gson, API client definitions, and sample GET and POST requests against httpbin.org. ### Source excerpt This post is about using Retrofit 2.0 (beta) to consume HTTP based APIs. Retrofit is a great and popular API client library for Java (and by extension also for Android) developed by Square. Here's a few links to start things off: Retrofit Homepage Retrofit Source on Github Retrofit Javadoc Blog post about Retrofit 2.0 Source code with samples for this post is available on Github. Retrofit makes it easy to develop API clients by describing API endpoints and the results like this: ## Use Apache HTTP Client on Android SDK 23 DevFeed: [Use Apache HTTP Client on Android SDK 23]() Original publisher: [Read original article]() Author: Marc Plano-Lesay Published: 2015-10-01T13:46:00Z Content type: tutorial Language: en Sources: [Marc Plano-Lesay]() Topics: [Android](), [HTTP](), [SDKs](), [Gradle]() Tags: [android](), [apache](), [build-system](), [client-library](), [deprecated](), [gradle](), [http](), [sdk]() ### AI overview This tutorial explains why applications using the Apache HTTP Client no longer build with Android SDK 23: Google removed the library's compile-time stubs, although the corresponding classes remained on Android 6 devices. It describes restoring the stubs through the Android build tools or directly using the provided JAR, while recommending migration to alternatives such as HttpURLConnection, OkHttp, or Ion. ### Source excerpt With the Android M SDK (API 23), Google removed the Apache HTTP Client library. It was deprecated since API 22, and Google recommended to use HttpURLConnection instead since API 9. While the classes are still bundled in Android 6 ROMs, it won't be long until we see them completely go away. Some applications are still relying on this library, and need to be updated to use the SDK 23, without having time/budget/whatever required to switch from HTTP Client. While I strongly recommend you to still take time to move to something else (there are many high-level libraries, like OkHttp or Ion, or you can use HttpURLConnection to keep a low-level access), there is a way to use the Apache library while using the SDK 23. ## Building NSQ Client Libraries DevFeed: [Building NSQ Client Libraries]() Original publisher: [Read original article]() Author: Wordbitly Published: 2013-05-09T18:58:23Z Content type: tutorial Language: en Sources: [Bitly]() Topics: [Messaging](), [client](), [configuration](), [servers](), [HTTP]() Tags: [asynchronous](), [client-library](), [configuration](), [developers](), [distributed](), [guide](), [infrastructure](), [message-queue](), [messaging](), [nsq](), [tcp](), [thundering-herd]() ### AI overview A guide to the responsibilities and design expectations of NSQ client libraries, focusing on consumers. It covers configuration, discovery, TCP connections, message handling, pipelining, asynchronous processing, and techniques for maintaining cluster robustness and performance. ### Source excerpt Brace yourself, this is a long one. The following guide was originally intended for client library developers to describe in detail all the important features and functionality we expected in an NSQ client library. While writing it we began to realize that it had value beyond client library developers. It incorporates a comprehensive analysis of most of the capabilities of NSQ (both client and server) and is therefore interesting and useful for end-users as well (or anyone using or interested in infrastructure messaging platforms). If you need some background on NSQ please see our original blog post or its follow up, spray some NSQ on it. Intro NSQ's design pushes a lot of responsibility onto client libraries in order to maintain overall cluster robustness and performance. This guide attempts to outline the various responsibilities well-behaved client libraries need to fulfill. Because publishing to nsqd is trivial (just an HTTP POST to the /put endpoint), this document focuses on consumers. By setting these expectations we hope to provide a foundation for achieving consistency across languages for NSQ users. Overview Configuration Discovery (optional) Connection Handling Feature Negotiation Data Flow / Heartbeats Message Handling RDY State Backoff Configuration At a high level, our philosophy with respect to configuration is to design the system to have the flexibility to support different workloads, use sane defaults that run well "out of the box", and minimize the number of dials. A client subscribes to a topic on a channel over a TCP connection to nsqd instance(s). You can only subscribe to one topic per connection so multiple topic consumption needs to be structured accordingly. Using nsqlookupd for discovery is optional so client libraries should support a configuration where a client connects directly to one or more nsqd instances or where it is configured to poll one or more nsqlookupd instances. When a client is configured to poll nsqlookupd the polling int ## Asynchronous RPC in App Engine Today DevFeed: [Asynchronous RPC in App Engine Today]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2011-01-24T18:07:00Z Content type: tutorial Language: en Sources: [Guido van Rossum]() Topics: [Remote Procedure Call (RPC)](), [SDKs](), [client library](), [servers]() Tags: [appengine](), [asynchronous](), [client-library](), [fetch](), [python](), [rpc](), [sdk]() ### AI overview This article introduces low-level asynchronous RPC support in Google App Engine. It demonstrates sending requests to multiple remote service instances with urlfetch and using UserRPC.wait_any() to return the first completed result, while noting how to handle subsequent results and outstanding requests. ### Source excerpt While I was laying the groundwork for a new datastore client library with support for asynchronous requests, I added some low-level support for asynchronous RPCs that you can use today. The only App Engine API with documented support for asynchronous RPCs is urlfetch, and it happens to be quite useful with that. Suppose you want to fetch some data from a remote service. The remote service has two instances, both of which are slightly flaky. What you want to do is send off requests to both servers simultaneous (this is the easy part) and then wait for the first one to give you a result. The latter uses the new API that I'm about to describe here. from google.appengine.api import urlfetch, apiproxy_stub_map urls = ['http://service1.com', 'http://service2.com'] # Etc. rpcs = [] for url in urls: rpc = urlfetch.create_rpc(deadline=1.0) urlfetch.make_fetch_call(rpc, url) rpcs.append(rpc) rpc = apiproxy_stub_map.UserRPC.wait_any(rpcs) # Now rpc is the first rpc that returned a result. Have at it! That's all! If you're interested in learning more about this handy class method, just check out its docstring in the App Engine SDK. Note that technically you should loop until it doesn't return None. You can also repeatedly call wait_any() to get subsequent result. Make sure to remove the rpc it returns (if any) from the list, since otherwise it will return the same rpc over and over again: the specification of wait_any() says it returns the first rpc in the given list that completes, regardless of whether you have seen it before. Also note that there currently is no way to cancel the other RPCs, which is why I passed a low deadline to the create_rpc() call. The problem is that even if you completely ignore the other RPCs, the App Engine runtime still waits for them to finish or timeout. Finally, there is also a similar class method UserRPC.wait_all(), which waits until all RPCs in the list you pass it are complete. (It doesn't return anything.) PS. Don't look too closely at the