Comparing integration-resilience-engineer with vite
integration-resilience-engineer
View full →Author
@JetBrains
Stars
56
Repository
JetBrains/skills
Integration Resilience Engineer
Source mapping: Tier 2 high-value skill derived from Kotlin_Spring_Developer_Pipeline.md (SK-12).
Mission
Make integrations behave predictably under partial failure, timeouts, retries, and duplicate delivery. Treat every remote boundary as unreliable and every retry as a potential multiplier of load.
Read First
- External API or messaging contract, including status codes or message schema.
- SLA, timeout budget, rate-limit rules, and idempotency guarantees.
- Current client configuration, retry logic, circuit breaker settings, and scheduling configuration.
- Business criticality of the operation and acceptable degradation behavior.
- Existing observability around request outcome, retry count, queue depth, and DLQ.
Design Sequence
- Classify the operation:
- read-only or state-changing
- idempotent or non-idempotent
- synchronous user path or asynchronous background path
- Set timeout budgets from the caller's SLO backward.
- Decide which failures are retryable and which are terminal.
- Decide where deduplication or idempotency must be enforced.
- Add circuit breaking, bulkheading, or rate limiting where failure amplification is plausible.
- Add metrics, tracing, and structured outcome logging.
HTTP Client Rules
- Set connect and response timeouts explicitly.
- Retry only when the operation is safe to replay or explicitly idempotent.
- Use exponential backoff with jitter, not fixed-interval retries.
- Respect
429,Retry-After, and dependency-specific throttling semantics. - Distinguish timeout before request reached the server from timeout after side effects may already have happened.
- Map downstream errors into local semantics deliberately. Do not leak raw remote failures by accident.
Messaging And Scheduling Rules
- Treat consumers as at-least-once unless a stronger guarantee is proven end to end.
- Design deduplication with stable keys and durable storage when duplicate delivery matters.
- Use DLQ or poison-message handling instead of infinite redelivery loops.
- Be explicit about ordering guarantees and partition-key strategy.
- For scheduled jobs, prevent overlap with distributed locking when multiple nodes can run the same task.
- Account for clock skew, long-running jobs, and partial completion when scheduling recurring work.
Advanced Failure Modes
- Retries at multiple layers multiply explosively. One client retry policy plus platform retry plus queue retry can create storms.
- Circuit breakers without sensible fallback or operator visibility often only change the failure shape.
- Fallback data can become a stale correctness problem, not merely a degraded UX.
- A timeout on a state-changing call may leave the caller uncertain whether the remote side succeeded. This is an idempotency design problem, not just a timeout problem.
- DLQ without replay discipline creates permanent operational debt.
- Exactly-once is usually a system property claim, not an individual code property. Be skeptical and precise.
- If message schema evolution is expected, plan backward-compatible consumers before the first change arrives.
Boundary-Specific Nuances
- HTTP connection pooling, DNS caching, TLS handshakes, and per-host limits can dominate latency long before business logic does. Client-level transport settings matter.
- A
202 Acceptedplus asynchronous completion model may be safer than a synchronous state-changing call when dependency latency is unpredictable. - Outbox and inbox patterns solve different halves of reliability. Do not talk about one as if it covers both publish and consume idempotency.
- Kafka rebalance behavior, consumer lag, and partition skew are part of resiliency, not only throughput tuning.
- Schedulers need both overlap prevention and business-level idempotency. A distributed lock alone does not make the job semantically safe.
Expert Heuristics
- Put a retry budget around each integration path. If retries exceed the budget, fail fast and surface the degradation clearly.
- If a dependency is slow but not down, circuit breaking may be less useful than tight timeouts plus bulkheads.
- If the caller cannot safely determine whether a remote write succeeded, design a reconciliation path, not only a retry policy.
- If a queue consumer is critical, define operator behavior for DLQ replay before the first poison message appears.
Output Contract
Return these sections:
Failure model: what can go wrong at this boundary.Resilience policy: timeouts, retries, circuit breaking, bulkheads, fallback, and deduplication.Idempotency rule: how duplicate or uncertain delivery is handled.Operational signals: which metrics, logs, traces, and alerts are required.Minimal implementation plan: client, listener, scheduler, or config changes to make.Verification: chaos, integration, or replay tests that prove the design.
Guardrails
- Do not retry non-idempotent operations by default.
- Do not add retries without jitter and a retry budget.
- Do not use fallbacks that silently violate business invariants.
- Do not leave outcome ambiguity unexplained for timed-out state changes.
- Do not build resilience policies that operators cannot observe.
Quality Bar
A good run of this skill produces an integration policy that fails in controlled, explainable ways. A bad run adds retries and circuit breakers everywhere while increasing duplication, latency, and operational confusion.
vite
View full →Author
@JetBrains
Stars
56
Repository
JetBrains/skills
Vite
Based on Vite 8 beta (Rolldown-powered). Vite 8 uses Rolldown bundler and Oxc transformer.
Vite is a next-generation frontend build tool with fast dev server (native ESM + HMR) and optimized production builds.
Preferences
- Use TypeScript: prefer
vite.config.ts - Always use ESM, avoid CommonJS
Core
| Topic | Description | Reference |
|---|---|---|
| Configuration | vite.config.ts, defineConfig, conditional configs, loadEnv | core-config |
| Features | import.meta.glob, asset queries (?raw, ?url), import.meta.env, HMR API | core-features |
| Plugin API | Vite-specific hooks, virtual modules, plugin ordering | core-plugin-api |
Build & SSR
| Topic | Description | Reference |
|---|---|---|
| Build & SSR | Library mode, SSR middleware mode, ssrLoadModule, JavaScript API | build-and-ssr |
Advanced
| Topic | Description | Reference |
|---|---|---|
| Environment API | Vite 6+ multi-environment support, custom runtimes | environment-api |
| Rolldown Migration | Vite 8 changes: Rolldown bundler, Oxc transformer, config migration | rolldown-migration |
Quick Reference
CLI Commands
vite # Start dev server
vite build # Production build
vite preview # Preview production build
vite build --ssr # SSR build
Common Config
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [],
resolve: { alias: { '@': '/src' } },
server: { port: 3000, proxy: { '/api': 'http://localhost:8080' } },
build: { target: 'esnext', outDir: 'dist' },
})
Official Plugins
@vitejs/plugin-vue- Vue 3 SFC support@vitejs/plugin-vue-jsx- Vue 3 JSX@vitejs/plugin-react- React with Oxc/Babel@vitejs/plugin-react-swc- React with SWC@vitejs/plugin-legacy- Legacy browser support