Stop Copying HTTP Client Configurations Between Projects

Every backend project seems to start the same way. Someone creates an HTTP client, adds a timeout,...

Every backend project seems to start the same way.

Someone creates an HTTP client, adds a timeout, copies a retry configuration from another repository, and calls it a day.

A few months later:

• Requests start timing out under load
• Retries amplify incidents
• Slow downstream services consume all available connections
• Cascading failures appear across the system

The problem isn't the HTTP client.

The problem is that resilience strategies are usually treated as implementation details instead of architectural decisions.

What starts as a single slow dependency can quickly become a system-wide incident.

One Configuration Doesn't Fit All

A payment service and an analytics service should not share the same HTTP configuration.

Yet many teams use something like this everywhere:

const api = axios.create({
  timeout: 5000,
});

Or maybe:

const api = axios.create({
  timeout: 5000,
});

axiosRetry(api, {
  retries: 3,
});

This works.

Until it doesn't.

Different workloads require different resilience strategies.

A high-throughput internal service has completely different requirements from a low-latency API or an unreliable third-party integration.

That's exactly why I introduced Presets in Super HTTP TS.

Introducing Presets

Instead of forcing developers to manually configure every resilience component, Super HTTP TS provides presets optimized for common production scenarios.

Think of them as opinionated resilience profiles.

High Throughput

Designed for services that process a large volume of requests.

const client = createClient({
  baseURL: 'https://api.example.com',
  preset: 'high-throughput',
});

Optimized for:

• Connection pooling
• High concurrency
• Maximum throughput
• Minimal resilience overhead

Ideal for:

• Internal APIs
• Batch processing
• Event consumers
• High-volume microservices

When throughput matters, every unnecessary millisecond counts.

Low Latency

Designed for applications where response time matters more than retries.

const client = createClient({
  baseURL: 'https://api.example.com',
  preset: 'low-latency',
});

Optimized for:

• Fast failure
• Aggressive timeouts
• Predictable response times
• Reduced waiting

Ideal for:

• User-facing APIs
• Real-time systems
• Interactive applications
• Mobile backends

Sometimes failing fast is better than waiting longer.

Resilient API

Designed for external services and unstable dependencies.

const client = createClient({
  baseURL: 'https://api.example.com',
  preset: 'resilient-api',
});

Includes strategies such as:

• Retry
• Circuit Breaker
• Bulkhead
• Timeout Policies
• Fallbacks

Ideal for:

• Payment gateways
• Third-party APIs
• Legacy systems
• Unreliable external dependencies

Protect your system before downstream failures become your failures.

Why Presets Matter

The goal isn't to hide complexity.

The goal is to provide sensible defaults.

Most production incidents don't happen because developers don't know what a Circuit Breaker is.

They happen because resilience mechanisms are:

• Configured inconsistently
• Forgotten entirely
• Copied from unrelated projects
• Tuned without understanding the workload

Presets provide a proven starting point while still allowing full customization.

Inspired by Proven Patterns

Super HTTP TS was heavily inspired by concepts that have existed for years in the .NET ecosystem:

• HttpClientFactory
• Polly
• Resilience Pipelines

The idea was simple:

Bring these production-proven patterns into the TypeScript ecosystem with a developer experience that feels natural for Node.js teams.

What's Next?

Presets are only one piece of the puzzle.

The long-term vision for Super HTTP TS is to become a resilience-first communication layer for TypeScript applications, supporting both HTTP and gRPC workloads with a consistent API.

I'd love to hear your thoughts.

What preset would you add?

🔗 Documentation https://jhonesgoncalves.github.io/super-http-ts/

🔗 GitHub https://github.com/jhonesgoncalves/super-http-ts

🔗 My Website https://jhonesgoncalves.com