# client library A client library is software that provides a programming interface for interacting with an API, simplifying requests and handling communication details such as authentication. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## 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. ## 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. ## Configurable Features using Kotlin Multiplatform DevFeed: [Configurable Features using Kotlin Multiplatform]() Original publisher: [Read original article]() Author: Artem Zasypalov Published: 2023-09-01T06:55:38Z Content type: tutorial Language: en Sources: [YAZIO Engineering - Medium]() Topics: [Kotlin Multiplatform](), [multiplatform](), [Kotlin](), [configuration](), [Compose](), [business logic](), [Mobile](), [client library]() Tags: [business-logic](), [compose](), [configuration](), [development](), [feature-engineering](), [kotlin](), [kotlin-multiplatform](), [library](), [mobile](), [mobile-app-development](), [multiplatform](), [product-development](), [software-development]() ### AI overview YAZIO describes using Kotlin Multiplatform to make its onboarding feature configurable. A shared module provides configuration structures and validation for both the mobile app and a Compose Desktop Flow Configurator, allowing product teams to construct and experiment with screen flows without code changes for existing screen types. ### Source excerpt At YAZIO we love working efficiently. All business logic of our app's new features is written using Kotlin Multiplatform, and we share its code up to the ViewModels. This approach reduces engineering effort, increases stability, and conserves resources. We are always on the lookout for the next step. Some screens and even entire features require swift reactions in changing situations to provide the highest level of experience to our users. The first candidate was Onboarding. Our creative Product Team strives for excellence in first user impressions, meaning that changes in this part of the app occur more frequently than in others. That's why our Development department decided to make this feature not just flexible for content changes, but fully configurable. This means that engineering effort will be reduced to zero for changes that involve only existing Screen Types. Here comes our first term. A Screen Type is a combination of layout and business logic used for the screen in a Flow. And a Flow is a sequence of screens presented to a user in the feature. Our goal was to provide the Product team with a way to construct Flows and use them in the app without code changes. We took advantage of Kotlin Multiplatform again. First, we decided to have a single source of truth for both the app and the Flow Configurator. Configuration data structures and their validations are in a separate multiplatform module. This module is shared between our KMM client library with business logic and the Compose Desktop Flow Configurator app. In the Configurator, we can use our Screen Types to create screen instances and connect them to construct a Flow, create branching to cover all user's questions and concerns, and experiment with content and screen sequences. The saved configuration is then exported and used in the YAZIO mobile app. By delegating responsibility for screen sequences and content, we didn't neglect the safety of our solution. Each flow undergoes a series of validations to ## Sync GitHub repos to Notion with Temporal Schedules DevFeed: [Sync GitHub repos to Notion with Temporal Schedules]() Original publisher: [Read original article]() Author: Loren Sands-Ramshaw Published: 2023-06-06T04:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [GitHub](), [Notion](), [Databases](), [API](), [TypeScript](), [Back end](), [client library]() Tags: [api](), [database](), [github](), [library](), [notion](), [reliability](), [temporal-concepts](), [typescript]() ### AI overview This tutorial explains an internal tool that synchronizes a GitHub organization's repositories, members, and contributor data into a Notion database. It describes the TypeScript implementation using the GitHub API and Notion client library, and shows how Temporal Schedules runs the sync daily with durable-function retries and continuation after machine failure. ### Source excerpt For a company hackathon, I built an internal tool that syncs your GitHub org's list of repositories to a Notion database. Here's how it works and how I implemented it. ## 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. ## 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. ## 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 ## 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. ## 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: ## 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