Libraries & SDKs

Axios109.3k★

Axios is the JavaScript library most projects reach for to talk to APIs. It sends HTTP requests from the browser or Node.js with the same code and hands you back parsed JSON. Free under MIT, no paid tier. npm install axios, then axios.get or axios.post. What keeps it in stacks is interceptors (code that runs on every request or response, handy for attaching auth tokens or catching a 401 in one place), upload and download progress events, timeouts, cancellation and form serialization. The 1.x line is current and the old 0.x line still gets security releases. Nothing to host, so it's free whether you're solo, a small team or a large org. The catch is trust. On March 31, 2026 an attacker took over the lead maintainer's npm account and published two poisoned versions (1.14.1 and 0.30.4) that installed a remote access trojan; they were live for about three hours. Pin versions, commit your lockfile and run npm audit signatures. Also ask whether you need it at all: native fetch ships in every browser and current Node.js, Axios has no built-in retries, and a thin wrapper like ky or ofetch covers most apps with less code to trust.

requests54.6k★

Requests is how most Python code talks to the web. Python's built-in urllib works but reads like a punishment; Requests gives you requests.get(url) and a response that parses its own JSON. Sessions, cookies, auth, file uploads, redirects, proxies and TLS verification are handled for you. Free under Apache 2.0. pip install requests and you're done. There's nothing to host and no paid tier, so it's free for a solo script or a hundred-person team. It's still on 2.x (2.34 shipped in May 2026) and there's no 3.0 coming: the maintainers call it feature-complete and keep it in a perpetual feature freeze. Recent releases are maintenance, plus built-in type hints in 2.34. Needs Python 3.10 or newer. The catch: it's synchronous and HTTP/1.1 only. Fire off hundreds of concurrent API calls and each one waits its turn. For async work, look at aiohttp, httpx (requests-style API with async and HTTP/2, though it hasn't shipped a release since December 2024) or Niquests, a drop-in fork that adds async, HTTP/2 and HTTP/3. For scripts, CLIs and ordinary backend calls, Requests is still the right default.

pdf.js54.1k★

pdf.js is the library Firefox itself uses to show PDFs. It parses and renders PDF documents entirely in JavaScript, with no plugins and no native code. Apache 2.0, free, community-driven and supported by Mozilla. Nothing to host. Install pdfjs-dist from npm, load it from a CDN, or bundle it, and you get a complete viewer with form filling. It is more than display now. The built-in annotation editor handles free text, highlights, ink drawing, image stamps, signatures, and comments, and recent releases added a UI for merging and reorganizing pages. Releases land about monthly. Version 6.0 was a major release that raised the minimum supported browsers and changed parts of the API, so read the notes before upgrading. Solo through large: free, and the default answer for PDFs in the browser. Commercial SDKs like Apryse and Nutrient (formerly PSPDFKit) go further on document workflows, and they mostly price by quote. For creating PDFs instead of showing them, look at jsPDF or diegomura/react-pdf. The catch: it is JavaScript doing a native renderer's job. Large, graphics-heavy PDFs can be slow, and some documents with unusual fonts will not look identical to Acrobat. Test with your ugliest real files before you commit.

query50.5k★

Server data is not application state, but almost everyone stores it that way. TanStack Query fixes that: it handles caching, background refetching, request deduplication, pagination, and knowing when data went stale, so you stop writing the same useEffect plus loading plus error triangle in every component. MIT licensed, with adapters for React, Vue, Svelte, Solid, and plain JS. It is protocol agnostic, which matters more than it sounds. Query does not care whether you fetch over REST, GraphQL, tRPC, or a promise you wrote by hand. You hand it a key and a function and it owns the rest. The devtools panel alone earns the install, because watching cache entries go stale and refetch in real time is usually where the bug turns out to be. Nothing to run and nothing to pay. It lives in your bundle. The cost is conceptual: query keys are a cache namespace, and getting them wrong produces stale data that reads like a backend bug. Spend an afternoon on key structure before spreading it across an app. The catch is that Query is not a state manager and people keep using it as one. Client state, form state, and UI state still need their own answer. Keep Query on the server-data side of that line.

RxJava48.2k★

RxJava brings reactive programming to the JVM. It lets you treat streams of events, network calls, user input, database results, as data you can filter, combine, and transform with operators, instead of wiring callbacks by hand. Apache 2.0 and completely free, it has been a backbone of Android and server-side Java for over a decade. The power and the pain are the same thing: operators. There are hundreds of them, and composing them well takes real practice. Done right, RxJava turns gnarly asynchronous code into readable pipelines. Done wrong, it produces stack traces nobody can follow and subscriptions that quietly leak. The learning curve is steep, and the library is honest about that. If you are on the JVM and drowning in async complexity, RxJava is proven and battle-tested. Newer code has options, though. Kotlin coroutines and Flow cover much of the same ground with less ceremony, and Project Reactor is the default in the Spring world. Use RxJava when you are already in its ecosystem or need its exact operator set. For greenfield Kotlin, look at coroutines first. The catch: this is a library, not a product, and reactive is a paradigm you adopt team-wide or not at all. Half your codebase reactive and half imperative is worse than either one. Commit to it or skip it.

ky17.1k★

Ky wraps Fetch in a tiny, elegant API that handles all of it. Same author as Got, but built on Fetch so it works in browsers, Deno, Bun, and Node 18+. MIT licensed. It's intentionally small, about 5KB. You get retries on failure, timeout support, hooks (beforeRequest, afterResponse), and JSON shortcuts. ky.get(url).json instead of const res = await fetch(url); if (!res.ok) throw.; return res.json. Fully free. npm package, no service, no paid tier. The catch: Ky is minimal by design. If you need advanced features like request cancellation with progress tracking, HTTP/2, or streaming uploads, Got or Axios have more batteries included. And since Ky is built on Fetch, it inherits Fetch's limitations: no built-in cookie jar, no proxy support in Node without extra config. For pure API calls where you want a thin wrapper over Fetch, Ky is perfect. For complex HTTP needs, it might not be enough.

react-pdf16.9k★

React-pdf lets you build them using JSX components. Instead of wrestling with a PDF library's API, you write <Document><Page><View><Text> just like you'd write a React component. The mental model is the same, the output is a PDF. Everything is free under MIT. No paid tier, no premium features. The library handles layout (flexbox-based), fonts, images, SVG, links, and page breaks. It works in Node.js (server-side generation) and in the browser. There's nothing to host for the library itself. npm install @react-pdf/renderer and start building. If you need server-side PDF generation at scale, you'll run a Node.js service, but that's your infrastructure choice. Solo developers: perfect for adding PDF export to a React app. Invoices, reports, anything you'd otherwise build with a Python PDF library. Small teams: great for any app that needs branded PDF output. The component model makes templates maintainable. Growing teams: it scales, but complex layouts with many pages can be slow to render. The catch: the flexbox layout engine is close to CSS flexbox but not identical. Some properties behave slightly differently, and you'll spend time debugging layout issues that "should work." Also, rendering speed. Complex multi-page documents can take seconds to generate. For high-volume PDF generation, you might want a dedicated service.

got15.0k★

Got handles all of it with a clean API. It's what axios wishes it was for server-side Node. MIT licensed, maintained by Sindre Sorhus (who maintains half the npm ecosystem). Got is specifically designed for Node.js, not the browser. It gives you automatic retries, request cancellation, HTTP/2 support, progress events, and RFC-compliant caching out of the box. Fully free. It's an npm package. No paid tier, no service, no account. The catch: Got is Node.js only. If you need a client that works in both browser and Node, use Axios or Ky. Got also doesn't support the Fetch API; it's its own thing. With Fetch now built into Node 18+, some teams are moving toward lighter Fetch wrappers instead. Got is feature-rich but it's also 2.2MB installed; if bundle size matters for your serverless functions, consider Ky or native Fetch.

kryo6.5k★

Kryo turns Java objects into compact bytes and back, much faster and smaller than Java's built-in serialization. You rarely see it, but it's inside tools you do: Spark uses it for shuffled and cached data, Hive for query plans, Flink as a fallback serializer. It's free under the BSD 3-clause license. Setup is a Maven dependency. The work is configuration. By default every class you write must be registered up front. A Kryo instance is not thread safe, so each thread needs its own or you use a pool. The default FieldSerializer stores no schema, so adding or removing a field breaks bytes you already saved; use TaggedFieldSerializer or CompatibleFieldSerializer for anything long-lived. The format assumes Java on both ends. For cross-language or long-term storage, Protobuf or Avro are the safer picks. There's no paid tier. Solo, small teams, larger teams: free. The catch: Kryo's own README says it is not designed to make deserializing untrusted data safe. Turn off required registration and a crafted payload can create any class on your classpath. That's how Spring Statemachine shipped a CVE rated 8.8 in June 2026. Keep registration on, and set setMaxArraySize (new in 5.7.0) when reading streams.

Apache KIE (Drools)6.3k★

Apache KIE is the new home of Drools, the Java rule engine that pulls business logic out of your code and into rules an analyst can read. The same repo now holds jBPM (workflow), OptaPlanner (scheduling and routing optimization) and Kogito (all of it as Quarkus or Spring Boot microservices). Instead of nested if-statements, you write DRL rules, DMN decision models or Excel decision tables. Apache 2.0 and free. Drools is a library pulled from Maven Central, so there's no server to babysit. The work is learning DRL and keeping rule sets governed as they grow. A few thousand rules with no owner is spaghetti in a different file. Support is the only paywall: IBM sells Business Automation Manager Open Editions (formerly Red Hat Decision Manager) and Aletyx sells enterprise builds, neither with public prices. Solo and small teams: free, though plain code is simpler until rules multiply. Larger teams where analysts own fraud or loan logic: free, plus paid support for an SLA. The catch: it's been in the Apache Incubator since January 2023, and the README warns releases may have incomplete licensing review. Releases are slow (10.2.0 in April 2026). Workflow-first? Camunda is the usual pick.

faraday6.0k★

Faraday is the standard HTTP client for Ruby, the layer GitHub's own Octokit gem sits on. You set up a connection once (base URL, headers, auth) and every request passes through a stack of middleware, the same Rack idea Rails uses on the server, so logging, JSON parsing, auth headers and raising on errors each live in one small plug-in instead of being copied into every call. MIT licensed and completely free. Setup is gem 'faraday'. It runs on Ruby's built-in Net::HTTP by default and supports Ruby 3.0+. Since 2.0 the other adapters (Typhoeus, Excon, Patron and friends) and most middleware moved into separate gems, so retries mean adding faraday-retry. JSON request and response handling still ships in core. There is no paid tier. Solo, small teams, larger teams: free. Simpler scripts are fine with HTTParty or plain Net::HTTP; Faraday earns its keep when you're writing an API client other people will use. The catch: 2026 brought three security advisories. A path like //evil.com could swap the base host and carry your Authorization header along, the first fix missed URI objects, and deeply nested query strings could crash a worker. Run 2.14.3 or later (1.10.6 on 1.x).

extism5.8k★

Extism is a WebAssembly (Wasm) plugin system. It creates a sandbox where third-party code runs safely, can't access your filesystem or network unless you explicitly allow it. It's essentially a bouncer for third-party code. You define what the plugin can do, compile it to Wasm, and Extism handles the execution boundary. Works from Go, Rust, Python, Node.js, Ruby, and more. BSD-3 licensed. Fully free and open source. The team behind it (Dylibso) offers consulting but the framework itself has no paid tier. The catch: WebAssembly plugins are powerful but the developer experience is still rough. Writing plugins means compiling to Wasm, which limits your language choices and debugging tools. The ecosystem is young. You won't find a marketplace of pre-built Extism plugins. This is for teams building platforms where extensibility is a core feature, not for adding a quick plugin system to a side project.

lettuce5.8k★

Lettuce is the Java client most Spring apps already use to talk to Redis: Spring Boot's Redis starter picks it by default. One thread-safe connection serves blocking, async and reactive calls, with Cluster, Sentinel, pub/sub, RediSearch and RedisJSON built in. MIT licensed, completely free. Nothing to host. Add io.lettuce:lettuce-core from Maven Central and point it at Redis. It still runs on Java 8, and Redis Ltd. ships releases steadily (7.7 through 7.9 landed August to October 2026). Free for solo devs, small teams and large teams. Your only bill is the Redis server. Lettuce for async, reactive or Spring work. Jedis, also from Redis, for a plainer client built for ease of use. Redisson for distributed locks, queues and Java collections on Redis, though its PRO edition is quote-only. The catch: sharing a connection only works if threads avoid blocking and transaction commands like BLPOP and MULTI/EXEC. And 8.0 is in beta, dropping Reactor-based APIs that 7.8 and 7.9 deprecated, so reactive code has migration work coming. Redis's server license change doesn't touch this: Redis lists Lettuce as MIT, and the client moved from Apache 2.0 to MIT in 2024.

Scalaz4.7k★

Scalaz was the library that brought Haskell-style functional programming to Scala: extra data structures and reusable abstractions the standard library leaves out. BSD 3-Clause, free, one dependency line. The honest summary today is that it is kept compiling, not developed. The record tells it. Stable 7.3.9 shipped in June 2026, 31 months after 7.3.8. As of September 2026, every human commit in the past year came from a single maintainer, and most of the rest were bots bumping dependency versions. The 7.4 line has been in milestone releases through M17, and the Scalaz 8 rewrite branch has not moved since 2019. It does still cross-build for Scala 2.12, 2.13, 3, Scala.js, and Scala Native, which is the point: existing code keeps working. Solo through large: free, and fine to keep if it is already in your codebase. Nobody has declared it dead, and the upkeep is real. For new projects, start with Cats and cats-effect, or ZIO. That is where the contributors and the ecosystem libraries are. The catch is a bus factor of one. A compiler change that one maintainer does not get to would strand you.

node-mysql24.4k★

MySQL2 is the MySQL driver Node.js actually uses. It speaks the wire protocol in pure JavaScript, no compiled bindings, and adds what the original mysqljs library never shipped: real prepared statements, the binary protocol, compression, and a promise API. Free, MIT licensed, and one of the most-installed packages in the Node ecosystem. There's nothing to operate. It's API-compatible with the old mysql package, so migration is usually a one-line change to your imports. Prepared statements aren't just safer against SQL injection, they're faster, because the server parses each query once. Every Node app talking to MySQL or MariaDB should be on this, either directly or through an ORM that wraps it. Prisma, Drizzle, and Sequelize all ride on top. Use it directly when you want SQL without an abstraction tax. The catch: it's a driver, nothing more. No migrations, no query builder, no failover logic beyond connection pooling. That's the point, but know what you're signing up for.

zip.js3.9k★

zip.js reads and writes zip files in JavaScript, in the browser, in Node, in Deno, and in Bun. It is not a wrapper around a native binary. It does the compression itself, in web workers, in parallel, which is why it can zip a folder of files in a browser tab without freezing the page. BSD-3 licensed and free. The feature list is why you would pick it over the smaller alternatives. Zip64 for archives past 4 GB, split archives, AES encryption, and streaming reads and writes so a 2 GB file never has to fit in memory at once. Recent releases added a filename validation option that rejects entries whose paths would escape the extraction directory, which is the zip-slip class of vulnerability you would otherwise have to defend against by hand. Nothing to operate. It is an npm install and an import. Solo developers building anything that lets a user download a bundle of files or upload an archive: this is the sensible default. Teams: same answer, and the streaming API is what keeps it working at file sizes where naive implementations fall over. The catch: this is essentially one maintainer's project, and releases ship every few days. That is a strength when your bug is fixed the same week you file it and a risk when you need to pin a version and trust it untouched for two years. The API surface is large and growing, so read the changelog before you upgrade rather than after.

libarchive3.7k★

libarchive is the C library that reads and writes basically every archive format you've heard of: tar, zip, 7-zip, cpio, ISO images, RAR, and more, with all the common compression codecs underneath. If you've used bsdtar on a Mac or BSD system, you've used libarchive, it ships those command-line tools too. It's plumbing, the kind that quietly powers other software. There's nothing to run or host. You link it into your C or C++ program, or use the bundled bsdtar and bsdunzip from the command line. One useful trait: it streams, so it can handle archives too big to fit in memory, reading and writing on the fly instead of loading the whole thing. Developers who need to handle archive files inside their own software are the audience, this saves you from shelling out to a dozen format-specific tools or writing format parsers by hand. For everyday compression at the command line, your OS tools are fine. libarchive earns its place when you're building something that has to deal with archives programmatically. The catch: it's a building block, not a product, so there's nothing here for a non-developer. It's BSD-licensed and rock solid, the kind of dependency you adopt and forget. The only real risk is the usual one with format parsers, archive handling has a long history of security bugs, so keep it updated.

Axon Framework3.6k★

Axon Framework is a Java toolkit for building systems where every change is stored as an event (event sourcing) and reads are split from writes (CQRS). It gives you the command, event, and query plumbing so you are not inventing it. The core is Apache 2.0 and AxonIQ says it stays free. The important word is core. Version 5 drew a harder line between free and paid. The Axon Server connector moved out of the open source repo into AxonIQ's commercial modules, along with the Postgres event store, dead-letter queue, distributed messaging, and multi-tenancy. What stays free for storage is a JPA engine on your own database, plus an in-memory one that is not for production. Axon 5 needs JDK 21 and Spring Boot 3, and version 4 reached end of life on June 30, 2026. Solo and evaluation: the free Individual plan is non-production only. Companies under 20 employees: Team from $150/mo billed yearly. Under 40 employees: Small Business from $1,750/mo. Larger: Enterprise, contact sales. Staying fully free means JPA storage and wiring up your own message distribution. The catch: Dynamic Consistency Boundaries, the headline feature of version 5, does not work on the free JPA store. It needs Axon Server or a paid extension. Sagas and the DeadlineManager are gone in version 5 too, so moving from 4 to 5 is a rewrite in places, not a version bump.

clickhouse-go3.4k★

ClickHouse is the database teams reach for when Postgres analytics queries start taking minutes. This is the official Go client, maintained by the ClickHouse team under Apache 2.0. It offers two ways in: a native interface that encodes columns directly, and a standard database/sql driver that drops into ORMs you already use. The native path is faster. Nothing to operate, it is a library. What matters is the thing it talks to, and self-hosted ClickHouse is Apache 2.0 and free. The driver handles connection pooling, failover across addresses, and LZ4 or ZSTD compression with no extra config. Bulk and async inserts are first-class, because ClickHouse punishes row-at-a-time writes. Use it if you write Go and touch ClickHouse. There is nothing to weigh it against: ch-go is the lower-level library this one builds on, not a competitor. Every team size gets the same thing for free. Cost appears only if you choose ClickHouse Cloud over running it yourself. The catch is version churn. Recent releases test against only the two newest Go versions, so an old toolchain pins you to an old driver. Raw streaming for CSV, JSON and Parquet is still experimental and works over HTTP transport only.

django-redis3.1k★

django-redis is the cache backend most Django apps reach for when the built-in one isn't enough. Django ships with caching, but it's basic. This swaps in Redis, the fast in-memory data store, as your cache and session store, with all the knobs production actually needs. BSD licensed, maintained under the Jazzband collective, free. What you get over rolling your own: native Redis URL connection strings, pluggable serializers, compression in half a dozen formats, primary and secondary replication, Sentinel support, distributed locks, and bulk operations by pattern. These are the things you don't realize you need until traffic shows up and the default cache falls over. It's a library, so running it is a pip install and some settings, but it assumes you already have a Redis server to point at. Shipping a Django app of any real size? This is close to a default choice, not a decision you'll agonize over. Solo projects can lean on the simpler built-in cache until they outgrow it. Teams running anything in production will want what this gives them. Free at every size, nothing to buy. The catch isn't django-redis, it's Redis itself. You still have to run, secure, and scale a Redis instance, and the recent licensing drama around Redis the product is worth knowing about even though this client doesn't change it. The library is the easy part.

nix3.1k★

This gives you safe, idiomatic Rust wrappers instead of raw unsafe libc calls. That's the whole pitch. The nix crate covers POSIX APIs across Linux, macOS, FreeBSD, and more. You get typed enums instead of integer constants, Result types instead of checking errno, and zero-cost abstractions over things like mmap, ioctl, and ptrace. It's been around since 2015 and is a dependency in hundreds of Rust projects. Everything is free. MIT licensed, no paid tier, no cloud service. You add it to your Cargo.toml and go. Solo developers building anything systems-level in Rust should already have this in their toolkit. Teams don't need to coordinate around it. It's a library, not infrastructure. The catch: it's Unix-only. Windows developers need something else entirely. And the API surface is massive. Not everything is equally well-documented. You'll occasionally hit a function that sends you straight to the man pages.

classgraph3.0k★

ClassGraph answers the question Java reflection can't: find every class implementing an interface, or carrying an annotation, across the whole classpath, without loading any of them. It reads raw classfile bytecode, which is how DI containers, plugin systems, and annotation processors discover things at startup. MIT, a decade-plus old, and unusually well maintained; the issue tracker sits at zero. There's nothing to run. It's a Maven or Gradle dependency, now split into modular artifacts so you pull only what you need. JDK 17+ required, and scanning is multithreaded to near I/O limits. This is infrastructure for people building tools other developers use: framework authors, plugin architectures, Android build tooling. For inspecting one class you already hold, plain reflection is fine. The main OSS alternative is the older Reflections library, which is effectively unmaintained; there is no commercial product in this category. The catch: the JDK's strong encapsulation keeps tightening, and reaching legacy classloader internals already requires an extra dependency. The maintainer flags it himself; this whole category is on a slow collision course with the JVM's hardening roadmap.

cccl2.6k★

cccl is NVIDIA's official bundle of the three core C++ libraries for CUDA: Thrust, CUB, and libcudacxx. In plain terms, if you write code that runs on an NVIDIA GPU, these are the building blocks (sort, reduce, scan, plus a standard library that works on the device) so you do not hand-roll GPU kernels from scratch. It is Apache-2.0 and ships with the CUDA Toolkit. Thrust is the high-level layer: parallel algorithms with an interface close to the C++ standard library, portable across GPU and multicore CPU backends. CUB is the low-level, speed-of-light layer for people writing custom kernels. libcudacxx is the CUDA C++ standard library. Most CUDA developers already use these without thinking about it. There is nothing to decide here. If you write CUDA C++, you use CCCL. It is maintained by NVIDIA, unified into one repo, and free. The only catch is the obvious one: it is CUDA, so it is NVIDIA hardware only. If you need to run on AMD or Apple Silicon, this is the wrong stack and you are looking at SYCL, ROCm, or Metal instead.

javascript2.3k★

The official Kubernetes JavaScript client, @kubernetes/client-node, lets Node and TypeScript code do what kubectl does: list pods, create namespaces, watch for changes, exec into containers, tail logs, copy files and port-forward. It's generated from the Kubernetes API, lives in the same kubernetes-client org as the Python and Java clients, and is Apache 2.0 and free. npm install @kubernetes/client-node and it reads your kubeconfig the way kubectl does. Version 2.0 (August 2026) moved the HTTP layer to undici, Node's own fetch engine, dropped Node 18, 20 and 23, and targets Kubernetes 1.36. CI tests Node 22, 24, 25 and 26. No paid tier: free for solo devs, small teams and large teams. Reach for it when building operators, internal dashboards or CI scripts in Node. Want a friendlier layer? Pepr's kubernetes-fluent-client wraps this library with a fluent API. Skip GoDaddy's older kubernetes-client, untouched since 2023. The catch: it's generated code, so expect a big, mechanical API with one class per API group (CoreV1Api and friends) and breaking majors, like 2.0's HTTP swap. Multiple kubeconfigs aren't fully supported because cached credentials can collide by username, and the README's compatibility table still stops at 1.4.x.

REDox1.7k★

RE:Dox is a .NET library from CAPCOM for reading, editing and converting structured data: JSON, JSON5, CBOR, MessagePack and INI, with TOML, XML, HTML and CSV in preview. Everything lands in one compact token model, so the same code handles every format. It's a piece of REX, CAPCOM's next-generation engine tech, released under Apache 2.0. It's a NuGet package (dotnet add package CAPCOM.REDox), so there's nothing to host. CAPCOM's own benchmarks show up to about 1.8x faster deserialization and 1.6x faster serialization than System.Text.Json, with much less memory allocated, though the README warns those aren't universal guarantees. Compatibility layers for System.Text.Json and Newtonsoft.Json let you try it without rewriting everything. Teams on .NET 10 with heavy serialization work (game tools, data pipelines, config-heavy apps) should benchmark it against their real payloads. Everyone else is fine on System.Text.Json. Game developers drawn in by the CAPCOM name should know this isn't engine code, just a serializer. The catch: it requires .NET 10, which rules out .NET 8 LTS shops and likely Unity. Half of its 12 packages, including both compatibility layers, are preview, and v1.0.1 shipped breaking changes five days after v1.0.0. The GitHub org isn't verified, though capcom.com commit emails and CAPCOM's own conference page back it up.

sling1.7k★

Go's net/http makes you assemble every HTTP request by hand. Sling is a small library that makes building and sending those requests less tedious. Instead of manually constructing http.Request objects, setting headers, encoding query parameters, and parsing responses, Sling gives you a chainable builder pattern. A Go equivalent of Python's requests library, but lighter. MIT license, Go. The API is clean: sling.New.Base(url).Get(path).QueryStruct(params).ReceiveSuccess(response). Supports JSON encoding/decoding, form data, custom headers, and base URL composition. No external dependencies beyond the standard library. Fully free. It's a library. Install it with go get, use it in your code. No service, no hosting, nothing to pay for. The catch: this is a mature-but-quiet project. The Go standard library's net/http is already good. Sling saves typing but doesn't add capabilities. If your team has strong opinions about minimizing dependencies, the standard library does everything Sling does with more code. And for complex API clients, you might want a full SDK generator like OpenAPI instead of a request builder.

requests-cache1.5k★

requests-cache adds persistent caching to Python's requests library. Pip install it, wrap your session, and identical HTTP calls return cached responses instead of hitting the network. Backends include SQLite (default), Redis, MongoDB, DynamoDB, and flat files. Install and a one-liner to enable caching on your session. No service to run. The default SQLite backend lives in ~/.cache/. Switch backends with a parameter when you need persistence across machines or processes. Pick this for code that hits the same API repeatedly: scrapers, data pipelines, ETL jobs, integration tests against rate-limited services. Solo and small teams: drop it in, pays for itself the first time you stop hammering an API. Large teams at scale probably want a dedicated cache layer (Redis, Varnish, CDN), but this is still useful for the long tail. The catch: cache expiration is your problem. By default cached responses live forever; you set expire_after or rely on Cache-Control headers. Forget that and your scraper happily serves six-month-old data.

pydantic-sqlalchemy1.4k★

pydantic-sqlalchemy does one small thing: it turns your SQLAlchemy database models into Pydantic models automatically. If you use both in a Python project, FastAPI is the common case, you otherwise end up hand-writing a second set of models that mirror your tables. This generates them for you. MIT-licensed and free. It's a tiny utility from the author of FastAPI, and it's labeled experimental, not a polished library you build a system on. For a quick script or a small project where you want Pydantic schemas off your existing tables without the boilerplate, it saves real typing. The catch: modern stacks mostly solve this differently now, with SQLModel (also from the same author) combining SQLAlchemy and Pydantic into one model, or by generating schemas directly. Reach for this only if you specifically have separate SQLAlchemy models and want Pydantic versions fast. Otherwise, SQLModel is probably the better starting point.

cnfast1.2k★

cnfast does the same job as the cn helper in every shadcn/ui project: it merges Tailwind class names so the right utility wins when two conflict (the thing that lets p-2 and p-4 resolve cleanly instead of fighting). It rolls clsx and tailwind-merge into one package and runs them faster, around 3.8x on average and up to 7x in component-heavy code, with byte-identical output. MIT-licensed, free, on npm. Nothing to operate. It's a dependency. The speed comes from caching and a tagged-template syntax, and since the output matches tailwind-merge exactly, swapping it in is a find-and-replace on your import. There's a shadcn registry entry if you want it dropped straight into an existing project. Solo: install it if className merging shows up in your render profiles, otherwise the default cn is fine. Small teams: low-risk swap, do it once and forget it. Large teams: the per-call savings add up across thousands of components, and the zero-breaking-change promise makes it an easy approval. The catch: this solves a problem most apps don't have. className merge time is rarely your bottleneck, and adding a dependency to shave microseconds off something you never measured is premature optimization. Profile first. If clsx plus tailwind-merge isn't showing up, you don't need this.