A high-performance NestJS application providing Ethereum gas prices and UniswapV2 swap calculations.
- Ethereum Gas Price API
- Fast, production-ready endpoint for current gas prices
- UniswapV2 Swap Calculations
- Get swap rates and output amounts for any token pair
- Redis Caching
- Fetch the gas price with low latency
- Node.js 20+
- Redis
- Alchemy API Key
- Clone the repository
- Copy .env.example into .env
- Provide ALCHEMY_API_KEY
- Install dependencies:
pnpm installpnpm start:dev
Run all tests locally:
pnpm testOr view the latest test results in GitHub Actions.
curl -X GET "http://localhost:3000/api/v1/gasPrice" | jq
curl -X GET "http://localhost:3000/api/v1/return/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2/100" | jq
Transform gas price endpoint to achieve <5ms response times for production-ready, high-frequency applications.
| Scenario | Current | Proposed | Improvement |
|---|---|---|---|
| Cache Hit | 10-30ms | 0.1-2ms | 15x faster |
| Cache Miss | 200-500ms | 0.1-2ms* | 200x faster |
| P95 Response | 50ms | <5ms | 10x faster |
*After initial warmup
Memory Cache (0.1ms) → Redis Cache (2-5ms) → Blockchain RPC (200ms+)
- Return cached data instantly
- Refresh in background
- Zero user-facing cache misses
- Background refresh every 10s
- Cache always ready on startup
- Eliminates cold start delays
- Track response times per request
- Monitor cache hit ratios
- Alert on performance degradation
Phase 1: Enhanced Cache Layer
- Add in-memory caching to existing
CacheService - Implement LRU eviction and stale-while-revalidate
Phase 2: Background Refresh Service
- Create
GasPriceCacheServicewith active warming
Phase 3: Monitoring & Optimization
- Performance middleware and metrics
- Production configuration tuning
- Clean modular architecture with SoC
- Redis integration for gas price caching with TTL management
- Global exception filter and logging interceptor
- Class-validator integration with transformation
- Containerized with non-root user security
- Unit tests for core services
Current Decision: Simple Redis caching with 30s TTL for gas prices
Why: Reduces blockchain RPC calls and improves response times
Limitation: Basic caching without cache warming or invalidation strategies
Current Decision: Single provider (Alchemy) with simple connection
Why: Simple setup and reliable service
Limitation: No failover, rate limiting, or connection pooling
Current Decision: Environment variables with basic defaults
Why: Standard 12-factor app approach
Limitation: No validation, secrets management, or environment-specific configs
Current Decision: Global exception filter with basic logging
Why: Centralized error handling and consistent API responses
Limitation: No structured logging, error tracking, or alerting
- Environment-specific configuration files
- Secrets management
- Configuration validation on startup
- Rate limiting configuration per environment
- Multiple RPC provider endpoints
- Circuit breaker pattern for failed providers
- Connection pooling/retry mechanisms
- Provider health monitoring
- Cache warming to prevent cold cache hits
- Multi-level caching (memory + Redis)
- Cache metrics and monitoring
- Structured logging with request IDs
- Health checks with dependency status
- APM integration for request tracing
- Error tracking (Sentry)
- API rate limiting per endpoint/user
- Request/response validation with validation library
- API key authentication
- Request size limits
- Database for analytics and historical data
- Integration tests
- Load testing with realistic traffic
- End-to-end testing pipeline
- Kubernetes deployment with HPA
- Multi-environment deployment pipeline