Preface: This article has been brewing for quite some time for me — built up over years of grievances, weaponized semantics, being forced to engage in everything from corporate jargon to vicious performance review settings, and the endless stop-start of software lifecycles. I've been building software for over 14 years. I've sat in the CTO chair twice, navigated the hiring and firing trenches, and sat in the management meetings. But above all else, I am a coder. Whether I'm deep in the terminal on Neovim (by the way) working on code or architecting an entirely new frontend build for a SaaS, my absolute love for this craft is what keeps me in the game.

This critique comes from a place of respect for the work and the people who do it. But it's also aimed directly at the near-apathy I've seen across modern management. I've worked under some truly incredible leaders, so this isn't a blanket condemnation, but if the critique feels "finger-pointy" to certain C-suite readers or PMs — good. The spotlight needs to be shined here. This is how some of the people actually building your products feel.

Side Note: We are going to get into the technical weeds here, making this one of my longer pieces. But if you've survived more than a month at a tech company, you'll be able to follow along and probably have a few opinions of your own pop up. Enjoy the min-TED talk.

TL;DR — Every tool, platform, and initiative promises to make your life easier. Here is a look at who's actually cashing in the improvement.

Somewhere in the last decade, "Developer Experience" stopped being a description and became a department. It got a Slack channel, a quarterly OKR, a slide in the all-hands deck w/a green arrow trending upward. Companies now hire dedicated DX engineers, run DX surveys, and ship DX roadmaps, all in service of a phrase that sounds, on its face, like it must mean "we care how this feels for you". I want to take that phrase seriously enough to actually interrogate it, because I don't think it means that, and I think the gap between what the term implies and what it actually optimizes for, is worth naming plainly.

This isn't an argument that better tooling is bad, or that companies investing in internal platforms are somehow 'acting in bad faith' or some such nonsense. Most of the individual engineers building this stuff are trying to help, genuinely, and some of what gets built under this banner is genuinely good! The critique here is one level up from the people — it's about the incentive structure the term operates inside of, and about who the heck actually ends up holding the receipt when a "dev experience win" gets reported up the chain (more than typically to some suit who couldn't care less, so long as it appeases the bottom line).

EaaS — Empathy as a Service

The term "User Experience" actually meant something radical when Don Norman coined it at Apple in the early 90s. He wanted to look past basic 'usability' and focus on the person living w/the product, rather than the engineers who built it. The beauty of good UX is that everyone wins: a happy user sticks around and spends money on some product they didn't even realize they needed, which directly helps the company succeed and realize what parts of the UX/UI works and doesn't work overall. The incentives match up perfectly.

The Importance of UX: Design should start from the person who has to live with the thing, not from the constraints of the engineering team that built it.

"Developer Experience" (DX) completely hijacked that empathetic language — talking about 'flow' and removing friction — but applies it to a totally different reality. As a dev, you aren't the customer. The code you write is absolutely the product (and don't you forget it!). So when a company invests in making your life easier, they aren't doing it actually for your sake. They're doing it so you can churn out more work (faster and more productively) on their timeline.

Think about the classic DX win: shrinking a local dev setup from 3 days down to something like 20 min. Nobody wants to spend 3+ days fighting dependency errors just to run npm run dev, so it feels like a massive win for you. But management didn't fund this fix because they were worried about your frustration levels or how stressed your Tuesday is turning out to be. They funded it because a '3-day onboarding delay' means that many more days of paying your salary before you actually ship anything to prod. Your relief is genuine, but to the business, it's just a happy accident. Their actual target was the "time-to-first-commit" (TTFC), a metric that lives on a completely different dashboard than your personal wellbeing.

What Actually Is Getting Measured Here

If you want to know what an organization actually cares about, don't read its values statement; read its dashboards. And the dashboards that live under the DX umbrella almost universally measure some version of the same underlying question: how fast, and how often, is code moving through the system? The most influential framework here is what's called DORA — DevOps Research and Assessment — which popularized 4 (now-canonical) metrics:

• deployment frequency

• lead time for changes

• change failure rate

• time to restore services

These are genuinely useful numbers. They tell you real, actionable things about the health of a delivery pipeline. What they do not do, and were never designed to do in the first place, is tell you anything about whether the humans producing that pipeline are actually doing okay or not. Which, in my humble opinion, is pretty damn important.

Sitting alongside DORA (try this out for fun if you want to test your patience) in most engineerings orgs is the older, blunter machinery of the stuff that makes us coders gag, story points and sprint velocity — an estimation technique originally meant as a rough, relative sizing tool for a team's own internal planning, which has (in practice and theory) calcified into a running scoreboard, by which all devs, designers, techs, and engineers are now measured on a weekly/quarterly basis. How exciting.

Velocity charts get compared sprint over sprint. Story point totals get rolled up into quarterly capacity planning. A number invented to help a team have an honest conversation w/itself (for management) about scope has, in most companies I've seen, mutated into a number used to have a much less honest conversation w/a team about performance, and more silently focused on who's the more productive coder.

A quick side note for you, there is actually a better process if you have the time to read this article as well from Atlassian on a slightly-alternate method of story points called, "Fibonacci Story Points". Worth the read, tbh.

None of these metrics — not DORA, not velocity, not the increasingly popular 'engineering productivity' dashboards vendors are happy to sell you — ask the only question that would actually constitute measuring experience: did the person doing this work feel supported, sustainably paced, and clear-headed while doing it? There is no chart for "I understood what I was building and why". Just the same as there's no burndown for "I wasn't context-switched into oblivion this week". The things that would genuinely indicate a good DX are largely unmeasurable in the format a dashboard requires, so they don't get measured; in most organizations, what doesn't get measured quietly, stops counting as a real metric.

This is honestly worth naming w/its actual title: Goodhart's Law — the observation that once a measure becomes a target, it stop being a reliable measure of the thing it was originally tracking. The moment "deployment frequency" becomes a number a team is implicitly evaluated on, you start seeing commits broken into smaller, more frequent deploys not because that's the right engineering call, but because it's the move that makes the chart look healthy.

The moment velocity becomes a target, story points quietly inflate (noticeably), tickets get sliced into smaller pieces to produce more 'completed' units per sprint, and the number goes up while the actual pace of meaningful work stays exactly the same — or slows, honestly — because everyone's now spending part of their attention managing the number instead of the actual work. The dashboards were never lying, exactly. They were just never measuring the thing DX claims to be about in the first place.

Another side note here: a great article from Splunk is also worth the read called, "What is Goodhart's Law?".

Mandatory "Convenience"

There's a small but load-bearing difference between a tool that optimizes for you, and a tool that just optimizes you, and almost the entire modern DX tooling market lives on the wrong side of that preposition.

A tool that optimizes for you starts from your actual friction and quietly removes it, and its success is measured by whether you personally, feel less friction. A tool that optimizes you starts from a metric someone else wants to move, and you are the input it's tuning to get there. Both kinds of tools can look, on a features page, identical.

Take AI code-completion tools. Now, standard issue at almost every single tech company, not to mention most other companies/firms based around marketing, technology, sales, statistics, the list goes on but you get my point. The pitch is unambiguously developer-centric: less boilerplate, faster iteration, more time for the interesting problems. And for a lot of day-to-day typing, that's genuinely true (for the most part).

But sat next to that pitch is a second, quieter one, aimed at leadership rather than devs: acceptance-rate dashboards, suggestions-per-engineer counts, "AI-assisted productivity" reports that get cited in the next tooling budget meeting. The tool didn't stop being useful because it's also being measured. But the reason it survived procurement was never really "devs reported feeling less friction"; it was "usage numbers justify the license cost". Which is a completely different sentence wearing the same tool's name tag.

The same substitution shows up in "focus time" tools, meeting-load dashboards, and the various flavors of engineering-analytics platforms (God knows how many there are nowadays) sold explicitly under the DX banner. Products whose marketing copy is soaked in words like toil, flow state (ew), and cognitive load, and whose actual customer — the person signing the invoice — is an engineering director trying to answer questions about headcount and throughput. A calendar analysis tool that tells you "you spent 11 hours in meetings this week" is framed as empowering.

Now you can reclaim your time! But the same data rolled up across a whole org, is at least as useful for justifying a reorg as it is for helping any individual dev protect the peace of a Tuesday morning. The dev-facing feature and the leadership-facing report usually ship in the same product at the same time, and from the same company.

I've watched this play out at a smaller scale too, the kind that doesn't make it into a case study. A team I worked w/once rolled out a new PR-description template, sold internally as a DX improvement — "it'll help reviewers understand context faster, so review turnaround improves for everyone." What it actually did was add 6 new required fields to every damn PR. Stuff like:

• testing checklist

• rollback plan

• risk assessment

• linked ticket

• screenshot requirement

And a section that absolutely nobody (including any PMs) could remember the purpose of. Review turnaround as a metric did improve, marginally, on the dashboard someone was tracking. The actual experience of opening a PR — for the person who had just spent the day writing all the code — got measurably worse, and stayed that way because the trouble had simply moved one step earlier in the pipeline, from the reviewer's side to the author's; and only one of those experiences was the one anyone was measuring.

The honest test for whether a tool is optimizing for you or just you is pretty simple, and almost nothing passes it: could you opt out, w/zero consequence to your standing, your reviews, or your next performance cycle? Most DX tooling is (at least in practice) mandatory. Mandatory convenience is a contradiction worth stewing over.

Follow The Convenient Yellow (Mandatory) Brick Road

Platform engineering is, in its best-intentioned form, a real answer to a real problem: devs were spending too much of their time hand-rolling infrastructure, wrangling Kubernetes manifests, and reinventing CI/CD deployment pipelines that a hundred other teams in the same company had already reinvented just ever so slightly differently.

The fix — internal dev platforms, standardized tooling, self-service infrastructure, list goes on — is (on paper) a legitimate act of care. Reduce the cognitive load of undifferentiated infrastructure work as the pitch goes (yawn), so devs can spend their attention on the actual problem they were hired to solve! Tools like Spotify's open-source Backstage popularized the concept of a 'golden path' — a single, well-supported, very opinionated route through the platform that's easier than doing it yourself from scratch. (Check this article out for a breakdown if you're interested.)

Here's where the strings show up. A golden path is only golden because it's the only path anyone will help you walk. Step off it even for a second — need a slightly different database, a different deployment cadence, a language the platform team didn't actually optimize for — and you don't just lose convenience, you often lose support entirely; sometimes explicitly, through the much quieter mechanism of nobody on the platform team having the bandwidth (hate that term) to help you w/the thing you weren't supposed to be doing.

What gets marketed as 'convenience' functions structurally as a mandate, and mandates that centralize how every team builds and ships are (not even incidentally) also mandates that centralize stuff like visibility and control for whoever owns the actual platform. That's not a criticism of platform teams by any stretch, who are usually just trying to keep an org from fragmenting into 40+ incompatible ways of doing the exact same thing. It's honestly a criticism of pretending the resulting control is purely a DX initiative rather than also, quite directly, an organizational-leverage one.

There's a specific irony that shows up once a platform matures. Devs now have to learn the platform team's abstraction on top of the underlying tech it was supposed to simplify, and that layer is sometimes more (a word I heard years ago and still love/hate) idiosyncratic, more specific to one company's internal priorities and conventions, and less transferable than the open tech it's wrapping. You can google a Kubernetes error message and find thousands of people who've hit the same wall as you.

But you can't google your own company's internal deployment tool's cryptic failure state or what failed pieces of the tech stack architecture didn't workout, because something like 5 people in the world have ever seen it, and 3 of the 5 are on the platform team, and none of them are answering Slack messages because it's Friday at 440pm and God forbid. When the abstraction leaks — and abstractions always eventually leak don't get tricked here — the dev who was "protected" from the underlying complexity now has less context to debug it than if they'd just been allowed to understand the real system from the start.

None of this makes Platform Engineering (PE) a bad idea. Standardization has real, legitimate value, and a well-run internal platform genuinely does remove a category of tedious work that nobody was excited to do by hand (can think of a few). The point is narrower than "platform engineering is secretly evil" — it's that the primary design constraint behind most internal platforms is purely (as I'm sure most of you know) organizational consistency and control, and dev relief is a real (but secondary) benefit that shows up in the marketing copy far more prominently than it shows up in the actual design review.

The Lie of "Moving Faster"

Okay so this is going to come off like the ramblings of a senior coder who has seen this kind of thing happen too much, so feel free to skip this part (as if this entire article thus far hasn't been exactly that).

Velocity, as a concept, was never supposed to be a performance number. In its original Scrum framing, it's a rough, team-internal planning tool — a relative measure of how much a specific team (with its specific quirks and context) tends to get through in a sprint — used mainly so that team can make its own honest guesses about what fits in the next one. It was designed to answer the question "what can we commit to?", asked by a team, of itself. It was never in fact designed to answer the question a lot of orgs now quietly use it for: "is this team performing?". Asked from 3 levels up the food chain, by someone who has never sat in a team standup or written a single line of code.

The DX-flavored language wrapped around velocity initiatives is almost always framed around the developer. "We want to remove blockers so your team can move faster"; "let's identify what's slowing you down". And sometimes that framing is completely sincere, and the blockers really do get removed, and the removal really does make the day-to-day work better. But look at where the resulting chart actually goes: it goes into a dang sprint review. It goes into a quarterly business review. It becomes a line on a slide that says the org is "shipping faster", presented to people whose job is forecasting and resourcing, not to the dev whose blocked Tuesday it used to represent. The initiative was described in the language of care for the individual. The artifact it produced was a forecasting input for the business.

The pressure this creates is specific and corrosive in a way that's easy to underestimate from the outside. A team's velocity can legitimately dip for reasons that have nothing to do w/laziness or dysfunction (no matter what some ugly people may tell you). Someone spent the sprint mentoring a new hire, someone else absorbed an incident and spent 3 days firefighting instead of shipping, a chunk of the team's attention went into a UX/UI design conversation that will save months of rework later but doesn't produce a single closed ticket this week.

None of that shows up as "verified value" on a velocity chart. It shows up as a dip, and a dip invites a question; the question — even when nobody intends it this way… — lands as "why weren't you productive (enough)". Aimed at people who were, in fact, doing some of the most valuable and least visible work available to them that week.

The deeper failure is that velocity and quality are not the same axis, and a team can absolutely post record velocity while quietly accumulating the exact tech debt, burnout, and corner-cutting that will show up as a 'crisis' 2 quarters later — at which point it gets treated as a brand new problem, worthy of a brand new DX initiative; rather than the entirely predictable consequence of having optimized the wrong number for the last 6 months. Velocity is a genuinely useful figure for a business that needs to forecast a roadmap. It has never been, and was never designed to be, a proxy for whether the people generating it are doing sustainable, healthy work. Calling it a "developer experience metric" doesn't change what it was built to measure.

It just changes who feels obligated to smile about the number going down.

Utopia, Unfunded

If companies actually showed any true interest in the developer experience, it wouldn't start w/a dashboard. It would start by asking devs/designers/engineers directly how their work feels, then acting on answers that resist clean metrics — like whether anyone had room to think clearly, felt safe admitting they were stuck, or worked at a sustainable pace.

Real DX isn't abstract. It contains a series of important variables that (in my experience) most of them go often overlooked.

• Protected Focus Time: Calendar blocks backed by enforced company policy; not ignored Slack posts.

• Fair On-Call: Rotations built w/actual backup coverage and real compensation.

• Safety Values: Structural permission to adjust a velocity target w/o it becoming a mark against you in your performance review.

• Opt-In Tooling: Software so good engineers want to use it, rather than mandatory workflows forced on the team.

Here is the true litmus test for any new DX initiative: Where do the results get reported to first?

If the first conversation is a sincere check-in asking devs, "Does this actually feel better?", it might be legitimate. If the first place it shows up is an executive slide-deck boasting about "improved engineering velocity", it was a productivity push all along, and therefore not necessarily healthy for the dev.

The people building internal tooling aren't villains. We just need to name things accurately. Call a velocity drive what it is. Call platform control a platform mandate. Reserve "Developer Experience (DX)" for the rare moments we actually optimize for the human doing the work, not the chart generated on someone else's way up the ladder.

One Last Thought…

On a final, personal yet public note here: if your workday feels like an ongoing state of fight-or-flight, remember that no velocity metric or dashboard is worth sacrificing your nervous system, and it most certainly isn't "just a part of the tech industry". Software engineering is what we do, not who we are, and your worth as a human is entirely separate and more important than how many story points you move across a board. Staying healthy matters here. The latest comments on your PR from your senior are not the end of the world, I swear (been there, trust me). If you're feeling overwhelmed, don't carry it alone, check in on yourself. Reach out to a close friend, talk to a therapist (highly recommend!), or simply step back from the keyboard and breathe for a minute — 'touch grass', as I've heard 3 different junior devs say in meetings. What "doing your best" looks like changes from day to day, and simply showing up today is, I promise you, more than enough. As they say in the south:

"Give yourself some grace. Because nobody else is gonna." ~TE.

References & Further Reading

I've compiled a list of the links I've not only put into this article w/love and care, but also things I've come across that I believe are beneficial reads for any good dev or engineer to checkout. Enjoy!

UX & Engineering Philosophy

• Putting People First: Don Norman — Medium

• Don Norman & Modern UX Origins — Interaction Design Foundation

DORA, Productivity Metrics & Goodhart's Law

• Time-to-First-Commit (TTFC) — EM Tools

• DORA Metrics Breakdown — GitLab Docs

• DevOps Research and Assessment (DORA) Framework — Atlassian

• DORA Quick Check Assessment Tool — DORA.dev

• Goodhart's Law & Systemic Measurement Failures — CNA

• What is Goodhart's Law? — Splunk

• 16 Developer Productivity Metrics Top Companies Use — DX Blog

Agile, Estimation & Velocity

• Fibonacci Story Points: A Better Estimation Method — Atlassian

• Capacity Planning in Scrum — Scrum Alliance

• What Is Scrum Velocity? — Wrike Scrum Guide

• Agile Velocity vs. Capacity — DX Blog

• Understanding Jira Velocity Charts — Jira Cloud Support

Platform Engineering & Golden Paths

• Spotify Backstage Official Open-Source Platform

• What the Heck is Backstage Anyway? — Spotify Engineering

• Platform Engineering Is Failing — Here's Why Infrastructure Comes First — The New Stack

• The Platform Engineering Illusion: Why Most IDPs Fail — Platform Engineering

• When Does a Startup Need Platform Engineering? — Medium (The AIExplorer)

Developer Health & Sustainable Pacing

• How I Stay Healthy as a Software Engineer — Leon Pahole

• Software Devs of Reddit: How’s Your Health?

• Prioritizing Physical & Mental Health as an Engineer

• The Health Cost of Being a Software Engineer — YouTube

• Health Implications of the Software Engineer Life—And How To Fix Them

// EOF

Preface: This is a bit of a long and detailed article, and while I have a greater point to this article, and I’m going to show you the fallbacks and best practices for how to go about avoiding Axios as a whole for your future software and web apps, I feel it necessary to give a brief (albeit technical) backstory to why I feel Axios on the whole has not only never been my go-to (unless a company I’m working w/already has it in place which unfortunately has happened), but will now absolutely continue never to be in any future software products or even side-projects I work on in my career. So bare w/me here, but I truly think it’s important to fill you in on the exact details of what happened, as far as we the public know.

The Gritty Start

On March 31, 2026, someone ran npm install on a fresh clone of a project depending on the npm package axios, and got a remote access trojan for their trouble.

Here’s what actually happened. An attacker compromised the npm account of Axio’s lead maintainer, not through a code vulnerability, but through a targeted social-engineering campaign against the maintainer directly. Roughly 18+ hours before the main event, they published a quiet, unassuming decoy package called plain-crypto-js, just to establish it as a normal-looking thing that had existed for a while.

Then, at 00:21 UTC, using the stolen credentials, they manually published axios@1.14.1 — bypassing npm's Trusted Publishing safeguard entirely, since that mechanism only applies to packages published through a verified CI pipeline, and a manual publish from a compromised account walks right around it. Around 40 minutes later, they did the same thing to the legacy branch with axios@0.30.4. Both versions quietly pulled in plain-crypto-js as a dependency (big uh oh) — a package that does not appear anywhere in the actual Axios source code, mainly because it isn't actually a part of Axios. It's a cross-platform remote access trojan, built for macOS, Windows, and Linux (all 3 of the main OS's in case you're unaware), which phoned home to what is called a 'command-and-control' server and then attempted to erase its own tracks before anyone was the wiser. The whole thing was live for a grand total of about 3 hours before it was discovered and pulled.

TL;DR — Axios Got Hacked.

Here are some figures you should know going into this article as well.

Axios sees somewhere north of 85+ million weekly downloads. A 3-hour window on a package that size is not a “near-miss” statistic. It’s a real number of real machines that got backdoored because a project somewhere in their dependency tree ran npm install at the wrong moment within such a short fraction of time. I realize 'backdoored' is not a word, but I'm making it a word because it fits so beautifully for the context of the situation.

To the Point

I’m not telling you this story to make you paranoid about npm as a concept — open-source at scale for sure requires trusting some semblance of code that you in fact did not write yourself, that’s the deal, that’s how the entire ecosystem functions (not perfectly, but smoothly). I’m telling you this story because it’s the cleanest possible illustration of a fact that gets treated as background noise until it isn’t: every dependency in your package.json file is code that runs w/the same privileges as the code you wrote yourself, maintained by people you've never met, updated on a schedule you have zero control over, and it takes exactly one singular compromised account to turn any of them into an attack vector. That's true of every single npm package available. It just so happen to be Axios's turn.

Which brings me to the actual point of this article. Axios exists to solve a specific, narrow problem: making HTTP requests from JavaScript (or TypeScript) w/o having to write a lot of repetitive boilerplate. That probelm does not require a 3rd-party dependency anymore. It requires fetch w/the async/await values; which has been sitting in every browser and in Node itself for years, and about 40-ish lines of code you write once, read in full, and never have to trust a stranger's npm account to maintain. Crazy concept nowadays I know…writing your own code.

The Myth of Fetch’s Verbosity

The standard argument against fetch goes something like: it's too low-level, you have to manually check the response.ok request, you have to manually call a .json() for the response data, there's no built-in timeout, no interceptors, no automatic error-throwing on a bad status code. All of that is true, and easily fixable. None if it is an argument for a dependency. It's an argument for writing about (like I said) 40 lines of your own code, exactly once (reusable things called functions are pretty great for this…), instead of installing someone else's several-hundred-kilobyte abstraction over the same lines of code — an abstraction mind you that comes w/its own maintainers, npm account, and its own attack surface, as in the last section I just demonstrated in detail.

Here’s what actually changed the calculus. When Axios first got popular, JavaScript’s story around asynchronous code was callbacks and, later, raw promise chains (genuinely awkward to compose/too verbose at the time of its inception). The async/await fixed that at the language level.

“De-structuring assignment” means pulling data and error off a returned object costs you zero extra lines. Native fetch has supported an AbortController (built-in timeout) — you get the timeout by writing about 6 lines around a controller, not by installing a library. Every specific complaint about fetch's verbosity is a complaint about the absence of a thin, specific wrapper, not an argument that the wrapper has to come from node_modules.

So build the wrapper. Once. Read every line of it. Nobody else’s compromised account or packages can touch it.

Building the Wrapper

The rest of this article builds a small, dependency-free HTTP client on top of native fetch w/using async/await, showing you how to setup and use stuff like:

• global-base URL

• request interceptors

• normalized error-handling

• closures and good old fashioned FP (functional programming)

• no classes/constructors/methods

• no this uses

Side Note: I am the type of programmer that prefers FP > OOP. If you disagree, and are more of an “object-oriented is better” person, that’s completely fine! (You’re just wrong and I hate you no worries). If you’ve spent any time around functional-style JavaScript, none of this will feel unfamiliar; it’s the same discipline applied to network requests instead of array transforms.

Step 1: A Configuration Closure, Not a Class

The instinct a lot of intermediate devs reach for here is a class ApiClient type of thing, with this.base_url set in a constructor. Skip it. A factory function that closes over its configuration and returns a plain old object of methods does the exact same job, w/no this binding footguns and no instantiation ceremony.

// Creating an API client is super simple
const create_api_client = ({ base_url = '', default_headers = {} } = {}) => {
    const request_interceptors = []; // new request array
    const use_request_interceptor = interceptor_fn =>
        request_interceptors.push(interceptor_fn); // push the data into the array
    // more to come, this is just the shape so far
    return { use_request_interceptor };
};
// Btw, you all need to quit the python method of never using semicolons. Stop it;

The create_api_client runs once at startup, and every method it returns closes over base_url, default_headers, and request_interceptors for the lifetime of the app. Nothing outside this function can reach the request_interceptors directly — the only way in is through the use_request_interceptor() function, which is the exact same encapsulation-through-closure pattern that makes const count = 0; inside a counter function private w/o a single access modifier keyword.

Step 2: Normalized Error Handling

This is the part most hand-rolled fetch wrappers get lazy about, and it’s the part that actually matters. Fetch’s promise only rejects on a genuine network failure (DNS not resolving, connection refused). A 404 or a 500 status is — as far as fetch is concerned — a perfectly successful round trip. If your wrapper doesn’t check for a green (good) status (response.ok) itself and convert a bad status into an explicit failure, every single call site in your app has to remember to do it manually, and someone eventually won't.

The fix: a wrapper that never throws to its caller and never hands back a ‘successful’ response for a failed request. Every call resolves to the same predictable shape, always: { data, error }. Easy to remember and use, I swear.

// Create a normalize error for both the response and request
const normalize_error = (message, status = null) => ({
    data: null, // initial data pull should be null
    error: { message, status },
});
// Notice the status parameter (optional btw) has a default null value,
// this is because the error object is a generic object,
// so you don't need to specify the status code

One shape. Every failure — a network error, a bad status code, a JSON parse failure — collapses into this same structure. No call site downstream needs a try/catch block of its own, and no call site needs to know or care why something failed to handle the failure correctly.

Step 3: Request Interceptors

So it’s a clunky term to be fair, but really an interceptor here is just a function that takes a request config and returns a (possibly modified) one. The most common real use is attaching an auth token to every outgoing request w/o repeating that logic at every call site, which can be beyond annoying as hell and tedious.

// Build out the request interceptors (async function)
const apply_request_interceptors = async (config, interceptors) => {
    let current_config = config; // this applies the config object to the first interceptor
    for (const int of interceptors) current_config = await int(current_config);
    // Loop through each interceptor and await the result and apply it to the config
    return current_config;
};
// NOTE: that the function opens up w/using the 'async' keyword to tell the
// browser that this is an async function and the await keyword is used to
// wait for the async function to complete or return a value before proceeding

The await inside the loop matters here. I wanted to make a note on how important the second part of async/await is — an interceptor might need to do something asynchronous itself, like refreshing an expired token before attaching it, and this makes that possible w/o the caller needing to know or really even care.

Step 4: The Core Request Function

This is where everything from the last 3 steps gets all wired together and put in place. Gear up, and pay attention!

// Create the actual API Client (this is important)
const create_api_client = ({ base_url = '', default_headers = {} } = {}) => {
    const request_interceptors = [];
    const use_request_interceptor = interceptor_fn =>
        request_interceptors.push(interceptor_fn);
    const normalize_error = (message, status = null) => ({
        data: null,
        error: { message, status },
    });
    const apply_request_interceptors = async config => {
        let current_config = config;
        for (const int of request_interceptors)
            current_config = await int(current_config);
        return current_config;
    };
    const request = async (path, options = {}) => {
        try {
            // Setup the request options and headers data
            const config = await apply_request_interceptors({
                ...options,
                headers: { ...default_headers, ...options.headers },
            });
            // Save the full API fetch to the response variable
            const response = await fetch(`${base_url}${path}`, config);
            // IMPORTANT! This runs a check to see if the request failed
            if (!response.ok)
                return normalize_error(
                    `Request failed with status: ${response_status}`,
                    response.status,
                );
            // Save the full response data as JSON and immediately return
            const data = await response.json();
            // Return the data and no error
            return { data, error: null };
        } catch (error) {
            // return the exact error message from the request
            return normalize_error(error.message);
        }
    };
    return { request, use_request_interceptor };
};

Notice what’s absent: no call site of request ever needs a try/catch block. Every failure mode — the network dying mid-request, a 404, malformed JSON in the response body — gets caught here, once, and normalized into the same { data, error } shape before it ever even leaves the dang function.

That’s the entire value proposition of this wrapper, and it’s the exact same ‘push mutation to a small, disposable, locally-scoped place instead of letitng it leak everywhere’ discipline that makes the .reduce() accumulator acceptable to mutate even in an otherwise-immutable codebase — request_interceptors is the one array in this whole file that gets mutated, and it's mutated in exactly one controlled spot; invisible to everything outside this closure.

Step 5: The Verb Methods

request alone works, but nobody wants to write-out client.request('/tickets', { method: 'GET' }) at every call site. Thin, specific verb methods on top of it:

// Now we'll add the API specific CRUD calls (Create, Read, Update, Delete)
const create_api_client = ({ base_url = '', default_headers = {} } = {}) => {
    // ...(same as above)...
    // The GET request
    const GET = (path, options) => request(path, { ...options, method: 'GET' });
    // The POST request
    const POST = (path, body, options) =>
        request(path, {
            ...options,
            method: 'POST',
            body: JSON.stringify(body),
            headers: {
                'Content-Type': 'application/json',
                ...options?.headers,
            },
        });
    // The PUT request
    const PUT = (path, body, options) =>
        request(path, {
            ...options,
            method: 'PUT',
            body: JSON.stringify(body),
            headers: {
                'Content-Type': 'application/json',
                ...options?.headers,
            },
        });
    // The DELETE request
    const REMOVE = (path, options) =>
        request(path, { ...options, method: 'DELETE' });
    // Return all the methods
    return { GET, POST, PUT, delete: REMOVE, use_request_interceptor };
};
// NOTE: We use the 'remove' word instead of 'delete', I'll explain why below.

The delete keyword is a reserved word as a variable name, not as an object property, so the internal function is named REMOVE and exposed on the returned object as delete. The callers get the natural client.delete(...) they'd expect, and nothing internal has to fight the parser to get there.

NOTE: I used uppercase words for these method calls but it is to show that these (while only lexical scope, not global) should be used as global keywords. I’m old school, and I was taught that global variables and functions should be uppercase to help separate them from localized (lexical) scope variables. Feel free to name them anything you’d like, again so long as they are not a reserved keyword in JavaScript.

So now we just need to wire it up once, at the edge of the app:

// lib/create_api_client.js (everything from steps 1-5 above)

// lib/api_client.js
import { create_api_client } from './create_api_client';

export const api = create_api_client({
    base_url: import.meta.env.VITE_API_BASE_URL,
    default_headers: { 'Content-Type': 'application/json' },
});
api.use_request_interceptor(config => {
    const TOKEN = localStorage.getItem('auth_token');
    if (!TOKEN) return config;
    return {
        ...config,
        headers: {
            ...config.headers,
            Authorization: `Bearer ${TOKEN}`,
        },
    };
});

Now setup a .env file:

# Create a (.env) file in the same directory,
# and add the following line:
VITE_API_BASE_URL=http://localhost:1337

Note: You can choose whichever Port # you’d like, so long as it’s not a currently used one like 3000 or something. I just prefer 1337 because of a silly old Leetspeak reference from an old comic. Feel free to not check it out.

The line import.meta.env.VITE_API_BASE_URL is Vite's environment-variable convention. This whole setup assumes a standard Vite client build, not a meta-framework doing anything clever w/the request lifecycle on your behalf (looking at you Next.js).

Wiring It Into React and Zustand

The point of building this as plain functions instead of a class is that it composes into any state layer w/o any ceremony. Here’s the part that actually matters architecturally:

Components should not know fetch even exists. Data fetching lives in the store. Components read state and call actions. This is where a state management system like Zustand comes in handy!

// store/use_ticket_store.js
import { create } from 'zustand';           // the 'create' function is not a default export in zustand
import { api } from '../lib/api_client';    // import the api info from what you createconst initial_state = {
    tickets: [],
    is_loading: false,
    error: null,
};
export const use_ticket_store = create(set => ({
    // import the initial_state object or simply put it right here;
    // dealer's choice.
    ...initial_state,
    fetch_tickets: async () => {        // notice the function call is async
        set({ is_loading: true, error: null });
        const { data, error } = await api.GET('/tickets');
        // Remember, the GET request method was uppercased in the api_client file
        if (error) {
        // Check for errors on the callback here as well
            set({ error, is_loading: false });
            return;
        }
        // Now set the tickets to the data and shut off the is_loading state
        set({ tickets: data, is_loading: false });
    },
}));

The fetch_tickets function is the only place in the entire app that knows /tickets is an endpoint, or that fetching it might fail. The component consuming this store doesn't import api, doesn't know the create_api_client function even exists, and absolutely does not contain a try/catch block. Now set it up:

// components/TicketList.jsx
import React, { useEffect } from 'react'; // React is no longer necessary; I do it anyway
import { use_ticket_store } from '../store/use_ticket_store';
import Loading from './Loading'; // a Loading component
const TicketList = () => {
    const tickets = use_ticket_store(state => state.tickets);
    const is_loading = use_ticket_store(state => state.is_loading);
    const error = use_ticket_store(state => state.error);
    const fetch_tickets = use_ticket_store(state => state.fetch_tickets);
    // Create a useEffect that will run every time the fetch_tickets function is called
    useEffect(() => {
        if (tickets.length === 0) fetch_tickets(); // check if tickets are empty
    }, [fetch_tickets]);
    if (is_loading) return <Loading />;
    if (error) return <h1>Something went wrong: {error.message}</h1>;

    return (
        <ul className='ticket-list'>
            {tickets.map(ticket => (
                <li key={ticket.id}>
                    {ticket.customer} - {ticket.status}
                </li>
            ))}
        </ul>
    );
};
export default TicketList;
// NOTE: Some people simply deconstruct here and do something like:
// const { tickets, is_loading, etc... } = use_ticket_store();
// I prefer to create each variable explicitly for each state slice.

This is the decoupling that actually matters; it’s worth being explicit about why.

If TicketList imports the api directly and calls api.GET('/tickets') itself instead of using a state store, every component that needs ticket data would need its own loading state, its own error state, and its own opinion about what 'failed' looks like. Centralizing the fetch inside the store means there's exactly one place that understands the network, and an unlimited number of components that just read a plain, predictable state shape. Swap the entire backend, change the endpoint, add caching — none of it touches a single component.

The Takeaway

The Axios incident wasn’t a failure of Axios as a project, and it isn’t really an argument specifically against Axios going forward either. The maintainers responded, the malicious versions got pulled, the ecosystem’s tooling did roughly what it’s supposed to do once the compromise was detected.

It’s an argument about the shape of the risk itself: the moment you add a dependency to your code, you’ve added a second party who can ship code directly into your production environment, and you don’t get to vet every release the way you’d review a PR (pull request) from your own team.

Fetch is not going to get compromised by a hijacked npm account, because it isn’t an npm package. It ships w/the runtime, it’s specified by a standards body, and the worst thing that can happen to your request-handling logic is a bug you personally wrote and can personally read, in a file that’s maybe 80 lines long, that you understand completely because you built every line of it yourself. That’s not a purity argument. It’s a risk-surface argument, and after March 2026, it’s a considerably easier one to make outloud.

Learn the platform first. Reach for a dependency only once you’ve confirmed the platform genuinely cannot do it, not before.

Sources on the March 2026 Axios compromise:

• Snyk’s technical writeup

• Huntress’s incident report

• maintainer’s own post-mortem on GitHub

// EOF

We take perfectly functional programming paradigms and bury them under massive object-oriented class structures. We take dynamic, expressive scripting languages and try to force them into the rigid, compiled boxes of the 1990s. We download 400MB of dependencies just to render a static blog post.

After 14+ years of writing software and documentation, building web applications, and consulting companies large and startup, I’ve decided to carve out a quiet corner here on Medium (and my personal tech blog) to talk about the craft of code — w/o the noise and slop.

My name is Tyler. I am a Senior Software Engineer who spends entirely too much time in a terminal environment configuring everything from legacy code on deprecated/backlogged systems, all the way to coding in the most up-to-date software repos for companies (and myself) — and I strongly prefer writing code that actually makes sense. It’s truly as simple as that.

What to Expect

If you know me from my other corners of the internet, you know I have a deep, abiding love for a highly specific set of tools: Vanilla JavaScript, React, Node, C, and Perl. I don’t chase the flavor-of-the-month meta-frameworks, and I truly believe Next.js is utter trash, and you only need “type safety” in rare instances across the board. I care about how things actually work at not only the high-level, but mainly the compiler and memory levels, dealing with low-level languages has become my true passion.

To kick things off on this publication, I’m currently writing two deep-dive series aimed at engineers who want to understand their tools rather than just copy-pasting from documentation or some outdated AI prompt.

Scheme in a Trench Coat: The Computer Science of JavaScript

Everyone loves to make jokes about JavaScript’s weird edge cases. Most of those jokes are lazy, and they obscure the fact that JS is one of the most brilliantly misunderstood functional languages ever designed. I’m going to tear the language down to the studs. I’ll show you the brilliant functional architecture Brendan Eich stole from Scheme, why the single-threaded Event Loop is a masterclass in concurrency, and how the V8 Engine’s JIT compiler essentially tricks your computer into running dynamic code at C-level speeds.

There’s More Than One Way to Write History: The Philosophy and Culture of Perl

Perl was the duct tape that held the early internet together, alongside C. But it’s not just some relic language of the 90s dot-com boom. I’ll explore how Larry Wall’s background in linguistics created a language that thinks like a human speaks rather than a machine, how CPAN laid the groundwork for every modern package manager (insert some stupid, lazy npm joke here.), and why a dedicated community of pragmatic engineers keeps the language thriving today. For example, did you know there’s a Perl Convention that still meets every year in South Carolina? Pretty neato.

React and Move On: The Pragmatist’s Guide to Sustainable Development

The JavaScript ecosystem has been obsessed lately with “fixing” React by wrapping it in layers of complexity, heavy build steps, and mandatory meta-frameworks (looking at you Next.js). But what if React was never the problem? This series strips away the vendor-driven hype cycle to look at what made React a dominant force in the first place: a simple functional composition, predictable state flow, and a commitment to keeping the UI predictable. I am moving past the framework fatigue to reclaim a pragmatic, sustainable approach to building web/software apps.

My Baseline

I believe strongly in FP — functional programming. I believe in composition over inheritance. I believe that writing software should feel like a craft, like art, not some bureaucratic chore that — in some companies, unfortunately — it has truly become.

If you are tired of the endless churn of the hype cycle as I call it, and want to get back to the core computer science of the tools that actually run the web and software itself, stick around. We’ve got a lot of ground to cover.

Welcome to my terminal.

// EOF