Most HTTP clients work perfectly.
Until production traffic arrives.
Then suddenly:
- Timeouts start happening
- Retries make things worse
- Connection pools become exhausted
- Downstream failures spread through the entire system
- Latency explodes
- Users start complaining
And engineers spend hours trying to understand why a "simple HTTP request" became a major incident.
The problem is rarely the HTTP client itself.
The problem is how we build communication layers around it.
The Hidden Complexity of a Simple HTTP Request
Most applications start with something like this:
const api = axios.create({
baseURL: process.env.API_URL,
timeout: 5000,
});
Looks harmless.
But production systems quickly demand more.
Soon we need:
- Retry strategies
- Circuit breakers
- Connection pooling
- Bulkheads
- Rate limiting
- Metrics
- Logging
- Distributed tracing
What started as a simple HTTP client eventually becomes infrastructure.
From a simple Axios instance to a full resilience layer.
The Same Problem Was Solved Years Ago
The .NET ecosystem faced this challenge long ago.
Microsoft introduced HttpClientFactory.
Later, libraries such as Polly became the standard way to implement resilience patterns.
Instead of treating resiliency as something every team had to reinvent, they made it part of the communication layer itself.
This dramatically improved consistency across applications.
The Cascading Failure Problem
A slow dependency rarely stays isolated.
One service becomes slow.
Retries start accumulating.
Connections remain occupied.
Latency grows.
Eventually the entire system starts feeling the impact.
One slow service can trigger a chain reaction across the entire system.
This is one of the reasons why resilience cannot be treated as an afterthought.
The TypeScript Gap
Node.js has excellent HTTP libraries:
- Axios
- Undici
- Native Fetch
- Got
But most of them focus on transport.
Not resilience.
As a result, every team eventually builds its own solution:
retry(...)
timeout(...)
circuitBreaker(...)
metrics(...)
logger(...)
Over and over again.
Building Super HTTP TS
Super HTTP TS was created to bring resilience-first communication patterns into the TypeScript ecosystem.
Inspired by concepts such as:
- HttpClientFactory
- Polly
- Resilience Pipelines
The goal wasn't to replace Axios.
The goal was to provide a production-ready communication layer that already understands resilience.
Today the library includes:
Retry Policies
client.retry(3);
Circuit Breakers
client.circuitBreak({
failureThreshold: 5,
timeoutMs: 10000,
});
Bulkheads
client.bulkhead({
maxConcurrent: 100,
});
Connection Pooling
pool: {
keepAlive: true,
maxSockets: 200,
}
Observability
Built-in metrics for:
- Requests
- Latency
- Retries
- Circuit trips
- Bulkhead rejections
- Errors
Plugins
client.use(new LoggerPlugin());
NestJS Integration
SuperHttpModule.forRoot(...)
HTTP + gRPC
A unified developer experience for both communication protocols.
Presets: The Missing Piece
One of the newest additions to Super HTTP TS is Presets.
Most teams don't need infinite customization on day one.
They need sensible defaults.
High Throughput
const client = createClient({
preset: 'high-throughput',
});
Designed for:
- High request volume
- Internal APIs
- Event processing
- Batch workloads
Low Latency
const client = createClient({
preset: 'low-latency',
});
Designed for:
- User-facing APIs
- Real-time systems
- Fast failure
- Predictable response times
Resilient API
const client = createClient({
preset: 'resilient-api',
});
Designed for:
- External APIs
- Payment gateways
- Third-party integrations
- Unstable dependencies
Instead of manually configuring every resilience pattern, you can start from a proven baseline.
One preset, multiple resilience strategies.
The idea is simple:
const client = createClient({
preset: 'resilient-api'
});
And immediately get:
- Retry
- Circuit Breaker
- Bulkhead
- Timeout Policies
- Connection Pooling
- Observability
Without having to wire everything manually.
HTTP and gRPC
Modern systems rarely use a single communication protocol.
That's why Super HTTP TS supports both HTTP and gRPC while maintaining the same resilience model and developer experience.
This allows teams to standardize communication patterns across different services without constantly switching mental models.
Resilience Should Be a First-Class Concern
A slow dependency can take down an entire system.
A badly configured retry strategy can amplify an outage.
A missing circuit breaker can exhaust resources.
These aren't HTTP problems.
They're architecture problems.
And architecture problems deserve architectural solutions.
Final Thoughts
Super HTTP TS was created from a recurring challenge I found across Node.js and TypeScript projects:
Every team was rebuilding the same resilience mechanisms around HTTP communication.
Retry logic.
Circuit breakers.
Connection pooling.
Observability.
The same patterns implemented repeatedly in different ways.
The goal of Super HTTP TS is simple:
Help teams build resilient communication layers without reinventing the wheel every time.
If you've ever copied an HTTP client configuration from another repository and wondered whether it was still the right configuration...
You're not alone.
And that's exactly the problem this project tries to solve.
Links
📚 Documentation
https://jhonesgoncalves.github.io/super-http-ts/
⭐ GitHub
https://github.com/jhonesgoncalves/super-http-ts
💼 Website
Feedback, ideas and contributions are always welcome.
Top comments (0)