Libraries & SDKs

Axios109.2k★

It wraps the messy parts of XMLHttpRequest (browser) and http (Node.js) into a clean, promise-based API that works the same in both environments. MIT license. You `npm install axios`, call `axios.get` or `axios.post`, and get back a promise with your data. It handles JSON parsing, request/response interceptors, timeouts, cancellation, and automatic transforms. The API is clean and the docs are solid. Everything is free. It's an npm package with no paid tier. The catch: the `fetch` API is now available everywhere (browsers and Node.js 18+). For simple requests, native fetch does what Axios does without adding a dependency. Axios still wins on interceptors, automatic retries, request cancellation (AbortController works but is clunkier), and upload progress tracking. But the gap is shrinking. For new projects, consider whether you actually need Axios or if fetch with a thin wrapper (like ky or ofetch) is enough. At it's not going anywhere, but you should know the alternative is already built into your runtime.

query50.3k★

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.8k★

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.

got14.9k★

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.

incubator-kie-drools6.3k★

Drools pulls your business logic out of your code and into rules anyone can read. It's a rule engine for Java: instead of burying "if the order is over $500 and the customer is new, flag it for review" inside a tangle of if-statements, you write it as a rule, and Drools evaluates thousands of them fast. Apache licensed, fully free, and it's the JVM standard for this job. This is a library you embed, not a service you run, so there's no server to babysit. The work is upstream: you model decisions in DRL or DMN, wire up the KIE setup, and keep the rule sets sane as they grow. That part takes real discipline. A few hundred rules is manageable. A few thousand with no governance becomes its own kind of spaghetti, just in a different file. If you're on the JVM and your decision logic changes faster than your release cycle, this is the tool. Solo devs and small teams rarely need it, plain code is simpler until the rules multiply. Larger teams with analysts who own the logic, insurance pricing, fraud checks, loan approvals, are exactly who it was built for. The catch is the learning curve. DRL is its own language, the docs are dense, and the project now sits under Apache incubation after Red Hat handed it over, so momentum is steady rather than exciting. Budget time to learn it before you bet a system on it.

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.

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.6k★

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.

Arduino_Core_STM323.4k★

This lets you program STM32 microcontrollers with the Arduino IDE instead of ST's heavier native toolchain. STM32 chips are the workhorses of embedded projects, drones, sensors, motor controllers, and their official tools have a real learning curve. This board-support core wraps them in the familiar Arduino API, so you write the usual setup and loop functions and it handles the rest. It's official, maintained by the stm32duino org, and free. Setup is about as easy as embedded gets. You paste a Boards Manager URL into the Arduino IDE, install the core, pick your board from a list of over a hundred, and flash over USB. Under the hood it's built on ST's official STM32Cube HAL and the GNU Arm toolchain, so you get real hardware support, not a toy abstraction. Newer versions need the Arduino IDE 2. If you're prototyping on a Nucleo or Discovery board, or moving an Arduino project onto more capable STM32 silicon, this is the fastest path. Hobbyists and makers get the most out of it. Serious firmware teams doing heavy debugging often still reach for PlatformIO or paid tools like Keil and IAR when they need deeper JTAG work, but for a huge range of projects the Arduino flow is plenty. The catch is the ceiling. The same Arduino abstraction that makes STM32 approachable also hides the low-level control that advanced embedded work eventually needs. You'll outgrow it on complex real-time or safety-critical projects. For everything up to that point, it's hard to beat free.

clickhouse-go3.3k★

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.5k★

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.

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.