Sponsored by

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had a great week.

Quick reminder!

I made a very short feedback form for the newsletter where you can share what you like, what you don’t, and what you’d like to see more of:

Newsletter Feedback Form

Help me improve the newsletter to make it more valuable and fun! It’ll take less than 5 minutes.

I’ll start implementing some of the feedback next week!

Receive Honest News Today

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

SDK For Dummies

I always pictured an SDK as some magical black box.

In reality, an SDK is a bundle of developer-facing tools for a platform or product: libraries, API clients, types, docs, CLIs, emulators, code generators, examples, or other helpers. What’s included depends on the SDK.

What Is an SDK?

An SDK (Software Development Kit) is basically a toolbox for developers.

They make the development process easier.

Stripe SDKs

What type of tools are in a SDK?

An SDK might include:

API clients/bindings — typed functions/classes that wrap network endpoints.
Libraries/helpers — authentication helpers, serialization, pagination, signing, retries, or validation when the SDK actually implements them.
Docs + examples — language-specific integration examples.
CLIs/dev tools — scaffolding, local emulators, debugging/testing utilities.
Types/models — structures and type definitions that improve IDE feedback and compile-time checking in typed languages.
Templates/code generators — project starters or generated clients.

A nice way to think of it is like a “starter kit” for a platform/tool.

How is an SDK different from an API, a framework, or a library??

That’s uh… that’s a good question. Here’s how I like to think of them:

SDK vs API vs Library vs Framework

API: An interface/contract exposed by software. A web API is one common example.
SDK: A toolkit designed to help developers build against a platform/product. It may wrap one or several APIs.
Library: Reusable code you call from your application. An SDK can contain libraries.
Framework: A larger application structure/runtime that typically calls your code at defined extension points. An SDK can include framework-specific integrations without itself being a framework.

Programming example: API vs SDK

Let’s raw dog a stripe request… (I hope you don’t have to do this).

API

// Raw Stripe HTTP API request — SERVER SIDE ONLY.
// Never expose a secret Stripe key in browser/client JavaScript.
const response = await fetch("https://api.stripe.com/v1/payment_intents", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.STRIPE_SECRET}`,
    "Content-Type": "application/x-www-form-urlencoded",
  },
  body: new URLSearchParams({
    amount: "2000",
    currency: "usd",
    "automatic_payment_methods[enabled]": "true",
  }),
});

const body = await response.json();

if (!response.ok) {
  throw new Error(`Stripe returned HTTP ${response.status}: ${JSON.stringify(body)}`);
}

console.log(body);

SDK

// Using Stripe’s server-side Node SDK
import Stripe from "stripe";

const secret = process.env.STRIPE_SECRET;
if (!secret) throw new Error("STRIPE_SECRET is required");

const stripe = new Stripe(secret);

const paymentIntent = await stripe.paymentIntents.create({
  amount: 2000,
  currency: "usd",
  automatic_payment_methods: { enabled: true },
});

console.log(paymentIntent.id);

What’s the difference?

Now the flow and structure looks similar, but the SDK is doing a lot more behind the scenes:

Building endpoint URLs and request shapes
Encoding/serializing inputs
Parsing responses into useful objects/types
Formatting authentication when appropriate
Consistent error objects
Pagination/retry helpers if the SDK provides them
Keeping language-specific details in one maintained package

If you call the HTTP API directly, you own more of those details yourself. That can be a feature when you want maximum control—but it’s more code and more behavior to maintain.

Why SDKs are (usually) worth it

Speed: Less boilerplate and a shorter path to a working integration.
Developer experience: Types, autocomplete, request builders, examples, and language-native errors can make integrations easier to understand.
Consistency: A maintained SDK can centralize authentication, serialization, pagination, retries, telemetry, and API-version behavior—but verify which features your SDK actually provides.
Maintenance: Official or well-maintained SDKs can absorb many API changes for you, but feature parity can lag and breaking SDK releases can still require migration work.

When not to use an SDK

You’re probably thinking:

Why doesn’t every API have an SDK? It sounds like an upgraded version.

Oh my sweet innocent developer… If only it were that simple.

Bundle size/cold starts: A large dependency can hurt browser bundles or serverless startup time.
Environment mismatch: It may assume Node/browser/native APIs that your Edge/Worker/Deno/Electron environment does not expose.
Opinionated abstractions: The SDK may hide headers, transport details, retries, or request shapes you need to control.
Security/audit requirements: You may need a very small reviewed dependency surface or custom signing/logging behavior.
Feature lag: A newly released API capability may exist before your language’s SDK exposes it.
Supply-chain risk: Every dependency is code you trust and update. Pin/lock versions, review release notes, and prefer maintained packages from the real publisher.

Server SDKs vs browser SDKs

This distinction matters a lot. A server SDK can safely use credentials that must remain secret because the code runs on infrastructure you control. Anything shipped to a browser/mobile client should be assumed inspectable by the user.

Never put server secret keys into frontend bundles just because the SDK technically imports there. Browser SDKs usually use public/publishable identifiers and delegate privileged operations to your backend.

Also remember that retries can repeat side effects. If an SDK automatically retries network failures, understand which operations are idempotent and whether the API uses idempotency keys or another deduplication mechanism.

“Should I use the SDK or just the API?”

Use the SDK if:

You want a faster, language-native integration.
The SDK is maintained, supported in your runtime, and exposes the API features you need.
Its abstractions make common tasks clearer rather than hiding behavior you need to control.
You are comfortable with its dependency, versioning, retry, and security behavior.

Use the API directly if:

You want a minimal dependency surface.
Your runtime is unsupported or the SDK adds meaningful bundle/startup cost.
You need exact control over transport, signing, retries, telemetry, or API-version headers.
The SDK lags a capability you need now.
The SDK is abandoned or from an untrusted publisher.

If you want to keep learning

APIs explained — the contract an SDK usually wraps.
Webhooks explained — how services push events to your app.
GraphQL explained — another way clients can query APIs.

iPhone 17, iPhone Air, AirPods Pro 3, and everything else announced at Apple's hardware event

From a new slim iPhone Air model to redesigned AirPods, here's what was announced at this year's Apple event.

Introducing upgrades to Codex

Codex just got faster, more reliable, and better at real-time collaboration and tackling tasks independently anywhere you develop—whether via the terminal, IDE, web, or even your phone.

Get Excited About Postgres 18

New to Postgres 18, features like asynchronous i/o, uuid v7, b-tree skip scans, and virtual generated columns.

Too many tools: How to manage frontend tool overload

Read about how the growth of frontend development created so many tools, and how to manage tool overload within your team.

When AI nukes your database: The dark side of vibe coding

As developers lean on Copilot and GhostWriter, experts warn of insecure defaults, hallucinated dependencies, and attacks that slip past traditional defenses.

Thanks to everyone who submitted!

Wow… that’s a lot again. Let’s do a harder one:

Trace the Path of the Word

Given a grid of letters, check if a word can be traced by moving up, down, left, or right from one letter to the next.

Write a function that returns the path as a list of [row, col] positions, or "Not present" if the word is not found/can’t be created.

Examples

trace_word_path("BISCUIT", [
  ["B", "I", "T", "R"],
  ["I", "U", "A", "S"],
  ["S", "C", "V", "W"],
  ["D", "O", "N", "E"]
])
output = [[0, 0], [1, 0], [2, 0], [2, 1], [1, 1], [0, 1], [0, 2]]

trace_word_path("HELPFUL", [
  ["L","I","T","R"],
  ["U","U","A","S"],
  ["L","U","P","O"],
  ["E","F","E","H"]
])
output = "Not present"

trace_word_path("UKULELE", [
  ["N", "H", "B", "W"],
  ["E", "X", "A", "D"],
  ["L", "A", "U", "U"],
  ["E", "L", "U", "K"]
])
output = [[2, 3], [3, 3], [3, 2], [3, 1], [3, 0], [2, 0], [1, 0]]

trace_word_path("SURVIVAL", [
  ["V", "L", "R", "L"],
  ["V", "A", "I", "V"],
  ["I", "O", "S", "C"],
  ["V", "R", "U", "F"]
])
output = [[2, 2], [3, 2], [3, 1], [3, 0], [2, 0], [1, 0], [1, 1], [0, 1]]

Notes

The target word will never be longer than the grid of letters.
Target word and the letters grid will be in upper case.

How To Submit Answers

Reply with

A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

New video! (I forgot to mention it here)

You like the thumbnail?

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

What'd you think of today's email?

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.

🦥SDKs For Dummies