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
Top comments (0)