Libraries & SDKs

ky16.9k★

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

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

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.

libarchive3.5k★

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.

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

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.

sling1.7k★

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.