DEV Community: Ali

Webpack Fast Refresh vs Vite

Ali — Thu, 18 Dec 2025 19:54:37 +0000

This article shares what felt fastest in the day‑to‑day development of ilert‑ui, a large React + TypeScript app with many lazy routes. We first moved off Create React App (CRA) toward modern tooling, trialed Vite for local development, and ultimately landed on webpack‑dev‑server + React Fast Refresh.

This article was first published on the ilert blog, and you can find the full version here.

Scope: Local development only. Our production builds remain on Webpack. For context, the React team officially sunset CRA on February 14, 2025, and recommends migrating to a framework or a modern build tool such as Vite, Parcel, or RSBuild.

Qualitative field notes from ilert‑ui: We didn’t run formal benchmarks; this is our day‑to‑day experience in a large route‑split app.

Mini‑glossary

Here are the helpful terms you will encounter in this article.
ESM: Native JavaScript module system browsers understand.

HMR: Swaps changed code into a running app without a full reload.
React Fast Refresh: React’s HMR experience that preserves component state when possible.
Lazy route / code‑splitting: Loading route code only when the route is visited.
Vendor chunk: A bundle of shared third‑party deps cached across routes.
Eager pre‑bundling: Bundling common deps up front to avoid many small requests later.
Dependency optimizer (Vite): Pre‑bundles bare imports; may re‑run if new deps are discovered at runtime.
Type‑aware ESLint: ESLint that uses TypeScript type info – more accurate, heavier.

Why we left CRA

ilert‑ui outgrew CRA’s convenience defaults as the app matured.

Here are the reasons that pushed us away from CRA:

Customization friction: Advanced webpack tweaks (custom loaders, tighter split‑chunks strategy, Babel settings for react-refresh) required ejecting or patching. That slowed iteration on a production‑scale app.
Large dependency surface: react-scripts brought many transitive packages. Installs got slower, and security noise grew over time without clear benefits for us.

Goals for the next steps:

Keep React + TS.
Improve time‑to‑interactive after server start.
Preserve state on edits (Fast Refresh behavior) and keep HMR snappy.
Maintain predictable first‑visit latency when navigating across many lazy routes.

Why Vite looked like a better solution

During development, Vite serves your source as native ESM and pre‑bundles bare imports from node_modules using esbuild. This usually yields very fast cold starts and responsive HMR.

What we loved immediately

Cold starts: Noticeably faster than our CRA baseline.
Minimal config, clean DX: Sensible defaults and readable errors.
Great HMR in touched areas: Editing within routes already visited felt excellent.

Where the model rubbed against our size
In codebases with many lazy routes, first‑time visits can trigger bursts of ESM requests, and when new deps are discovered at runtime, dependency‑optimizer re‑runs that reload the page. This is expected behavior, but it made cross‑route exploration feel uneven for us.

Qualitative field notes from ilert‑ui

Methodology: qualitative observations from daily development in ilert‑ui.

Our repo’s shape

Dozens of lazy routes, several heavy sections pulling in many modules.
Hundreds of shared files and deep store imports across features.

What we noticed

First‑time heavy routes: Opening a dependency‑rich route often triggered many ESM requests and sometimes a dep‑optimizer re‑run. Cross‑route exploration across untouched routes felt slower than our webpack setup that eagerly pre‑bundles shared vendors.
Typed ESLint overhead: Running type‑aware ESLint (with parserOptions.project or projectService) in‑process with the dev server added latency during typing. Moving linting out‑of‑process helped, but didn’t fully offset the cost at our scale – an expected trade‑off with typed linting.

TL;DR for our codebase: Vite was fantastic once a route had been touched in the session, but the first visits across many lazy routes were less predictable.

Why we pivoted to webpack‑dev‑server + React Fast Refresh

What we run:

webpack‑dev‑server with HMR.
React Fast Refresh via @pmmmwh/react-refresh-webpack-plugin and react-refresh in Babel.
Webpack SplitChunks for common vendor bundles; filesystem caching; source maps; error overlays; ESLint out‑of‑process.

Why it felt faster end‑to‑end for our team:

Eager vendor pre‑bundling: We explicitly pre‑bundle vendor chunks (React, MUI, MobX, charts, editor, calendar, etc.). The very first load is a bit heavier, but first‑time visits to other routes are faster because shared deps are already cached. SplitChunks makes this predictable.
React Fast Refresh ergonomics: Solid state preservation on edits, reliable error recovery, and overlays we like.
Non‑blocking linting: Typed ESLint runs outside the dev server process, so HMR stays responsive even during large type checks.

Receipts – the knobs we turned

1// webpack.config.js
2module.exports = {
3  optimization: {
4    minimize: false,
5    runtimeChunk: "single",
6    splitChunks: {
7      chunks: "all",
8      cacheGroups: {
9        "react-vendor": {
10             test: /[\/\]node_modules[\/\](react|react-dom|react-router-dom)[\/\]/,
11          name: "react-vendor",
12          chunks: "all",
13          priority: 30,
14        },
15        "mui-vendor": {
16          test: /[\/\]node_modules[\/\](@mui\/material|@mui\/icons-material|@mui\/lab|@mui\/x-date-pickers)[\/\]/,
17          name: "mui-vendor",
18          chunks: "all",
19          priority: 25,
20        },
21        "mobx-vendor": {
22          test: /[\/\]node_modules[\/\](mobx|mobx-react|mobx-utils)[\/\]/,
23          name: "mobx-vendor",
24          chunks: "all",
25          priority: 24,
26        },
27        "utils-vendor": {
28          test: /[\/\]node_modules[\/\](axios|moment|lodash\.debounce|lodash\.isequal)[\/\]/,
29          name: "utils-vendor",
30          chunks: "all",
31          priority: 23,
32        },
33        "ui-vendor": {
34          test: /[\/\]node_modules[\/\](@loadable\/component|react-transition-group|react-window)[\/\]/,
35          name: "ui-vendor",
36          chunks: "all",
37          priority: 22,
38        },
39        "charts-vendor": {
40          test: /[\/\]node_modules[\/\](recharts|reactflow)[\/\]/,
41          name: "charts-vendor",
42          chunks: "all",
43          priority: 21,
44        },
45        "editor-vendor": {
46 test: /[\/\]node_modules[\/\](@monaco-editor\/react|monaco-editor)[\/\]/,
47          name: "editor-vendor",
48          chunks: "all",
49          priority: 20,
50        },
51        "calendar-vendor": {
52          test: /[\/\]node_modules[\/\](@fullcalendar\/core|@fullcalendar\/react|@fullcalendar\/daygrid)[\/\]/,
53          name: "calendar-vendor",
54          chunks: "all",
55          priority: 19,
56        },
57        "vendor": {
58          test: /[\/\]node_modules[\/\]/,
59          name: "vendor",
60          chunks: "all",
61          priority: 10,
62        },
63      },
64    },
65  },
66};

1// vite.config.ts - Vite optimizeDeps includes we tried
2export default defineConfig({
3  optimizeDeps: {
4    include: [
5      "react",
6      "react-dom",
7      "react-router-dom",
8      "@mui/material",
9      "@mui/icons-material",
10      "@mui/lab",
11      "@mui/x-date-pickers",
12      "mobx",
13      "mobx-react",
14      "mobx-utils",
15      "axios",
16   "moment",
17      "lodash.debounce",
18      "lodash.isequal",
19      "@loadable/component",
20      "react-transition-group",
21      "react-window",
22      "recharts",
23      "reactflow",
24      "@monaco-editor/react",
25      "monaco-editor",
26      "@fullcalendar/core",
27      "@fullcalendar/react",
28      "@fullcalendar/daygrid",
29    ],
30    // Force pre-bundling of these dependencies
31    force: true,
32  },
33});
34

Pros and cons (in our context)

Vite – pros

Blazing cold starts and lightweight config.
Excellent HMR within already‑touched routes.
Strong plugin ecosystem and modern ESM defaults.

Vite – cons‍

Dep optimizer re‑runs can interrupt flow during first‑time navigation across many lazy routes.
Requires careful setup in large monorepos and with linked packages.
Typed ESLint in‑process can hurt responsiveness on large projects; better out‑of‑process.

Webpack + Fast Refresh – pros
‍

Predictable first‑visit latency across many routes via eager vendor chunks.
Fine‑grained control over loaders, plugins, and output.
Fast Refresh preserves state and has mature error overlays.

Webpack + Fast Refresh – cons
‍

Heavier initial load than Vite’s cold start.
More configuration surface to maintain.
Historical complexity (mitigated by modern config patterns and caching).

When we would pick each

Choose Vite if:

Cold starts dominate your workflow.
Your module graph isn’t huge or fragmented into many lazy routes.
Plugins – especially typed ESLint – are light or run out‑of‑process.

Choose webpack + Fast Refresh if:

Your app benefits from eager vendor pre‑bundling and predictable first‑visit latency across many routes.
You want precise control over loaders/plugins and build output.
You like Fast Refresh’s state preservation and overlays.

Learn more in the ilert blog.

AI-driven incident response with ilert’s MCP server

Ali — Mon, 08 Dec 2025 11:07:15 +0000

Model Context Protocol (MCP) is quickly becoming the standard way to connect AI assistants to other tools. To help ops teams take advantage of that shift, ilert has built an open MCP server that lets assistants like Claude and Cursor securely interact with ilert, from checking who’s on call to creating and managing incidents.
This post explains MCP in simple terms, why ilert invested in it, how the server is designed, and how you can connect your favorite MCP client today.

This is a shorter version of the article first published by ilert engineer Tim Gühnemann.

MCP Basics

The Model Context Protocol is an open standard that gives AI assistants a consistent way to access external tools and data. Instead of building one-off plugins for every assistant, MCP defines common interfaces for:

Tools (actions an assistant can take)
Resources (data it can read)
Transports (how communication happens)

In other words, MCP is like a “USB-C for AI apps”: one interface that works across many clients. With MCP, assistants can read data, run operations, and stream results in a way that supports permissions and audit trails — much more reliable than UI automation or brittle scripts.

Many clients already support MCP. Claude Desktop can connect to MCP servers through extensions and connectors, while Cursor lets you add them in Tools & MCP and use them directly in the IDE chat.

For ops teams, this means assistants can read incidents, alerts, and schedules and then act on them (acknowledge, escalate, resolve, create incidents) through permissioned API calls rather than screen scraping.

Reasons we introduced an open MCP server for ilert

AI agents are increasingly used where teams already collaborate: chats, terminals, and IDEs. ilert’s focus is to bring incident response into those environments while keeping access safe, scoped, and fully auditable.

Problem: AI assistants need a secure, consistent way to work with alerts and incidents across different clients — without custom integrations for each one.
Outcome: MCP lets ilert expose capabilities once and make them instantly usable in any MCP-compatible assistant. Less context switching, fewer handoffs.

Architecture of the ilert MCP server

Tech stack

Runtime: Deno + TypeScript
SDK: Official MCP TypeScript SDK
Transport: Streamable HTTP (recommended in the MCP spec)
Hosting: Remote MCP server at https://mcp.ilert.com/mcp

The server uses the official SDK to provide MCP-compliant tools, resources, and prompts. We expose it remotely over Streamable HTTP, which supports streaming responses, resumable sessions, and simple authentication headers — a good fit for enterprise environments. (stdio is supported too, but Streamable HTTP is the default recommendation.)

How we map ilert to MCP

ilert’s MCP server exposes tool actions that map directly to the ilert API and common DevOps/SRE workflows. Assistants can safely read context and take action on Alerts and Incidents without relying on UI scripting.

What you can do

Manage alerts: list, inspect, comment, acknowledge, resolve, escalate, reroute, add responders, and run predefined actions.
Open incidents: create incidents with severity, service, and responders right from your assistant.
Look up context: find users, services, alert sources, escalation policies, schedules, and your own profile.

Typical flow

Use read tools to gather context (e.g., services → alerts → alert details).
Suggest and confirm a write action (e.g., acknowledge or resolve an alert, create an incident, run an alert action).
Execute through scoped ilert API keys so everything stays permissioned and auditable.

Real-world scenarios

Scenario 1: Create an alert in ilert
Use your assistant to locate the right service, confirm severity, and create an alert through MCP tools — all without leaving your chat or IDE.

Scenario 2: Comment on an incident and resolve it
Ask the assistant to fetch the incident context, add an update, and resolve or escalate once confirmed — with every step logged via API scopes.

Learn more about ilert AI capabilities here.

How to reduce on-call friction using AI Voice Agent

Ali — Fri, 28 Nov 2025 15:22:29 +0000

*See how we at ilert use our AI Voice Agent to make on-call calls way smoother. It grabs incident context up front and plugs right into your call flows.
*

Even with great automation and observability, on-call still has one very human pain point: the phone rings, you wake up, and you have basically no context. In the first minutes of a critical call, you’re not fixing anything yet; you’re just trying to understand what’s going on.

At ilert, we built the AI Voice Agent to change that. Instead of connecting callers straight to a sleepy engineer, the agent speaks to the caller first, collects the essential details, and then routes the call intelligently using up-to-date incident context. That way, when an engineer does get pulled in, they’re starting with real information — not guesswork.

The full version of this post was first published on the ilert Engineering Blog by my colleague, ilert engineer Jan.

What problem are we solving?

On-call engineers often receive urgent calls with minimal or messy context. The result is predictable: they have to ask the same qualifying questions over and over before they can even begin to help. In a high-pressure situation, those minutes matter.

The AI Voice Agent takes that initial burden off the engineer. It gathers the key facts before escalation, so engineers can jump directly into troubleshooting. It can also reduce unnecessary wake-ups by checking for open incidents and letting callers know when an issue is already being handled. And because the agent lives inside ilert’s Call Flow Builder, it fits into your existing routing logic instead of forcing you to bolt on a separate system. You decide which information it should collect: names, contact details, incident descriptions, affected services, or custom fields that align with your workflow.

How it fits into our Call Flow Builder

If you’ve used ilert’s Call Flow Builder, think of the AI Voice Agent as one more node you can place wherever it makes sense. It will look like something like that:

The builder is a visual tool where each node represents a step in call handling. The AI node can greet callers, ask structured questions, enrich context, and then route or escalate based on what it learns.

Architecture overview

Under the hood, the agent is designed for fast, modular conversations with low latency. Twilio handles real-time audio streaming to and from callers, while a WebSocket channel connects ilert to OpenAI for conversational turns. The Call Flow Builder provides the configuration layer, letting you tune behavior without touching code.

Inside Call Flow Builder, the AI Voice Agent is just one of the nodes we at ilert provide. The builder is visual: you connect nodes to shape what should happen during a call, step by step. Since the AI is a node too, you can drop it exactly where it makes sense in your flow. Maybe right at the start to collect context, or later to handle a specific part of the conversation.

What the agent does in that spot is pretty simple: it talks to the caller naturally, figures out what they’re calling about, and collects the key details you want before anyone gets escalated. If you enable context enrichment, it can also look at live ilert data like open incidents, service states, or maintenance windows. That way, it doesn’t just follow a script, but it reacts to what’s actually going on right now and routes the call accordingly.
Hard parts we had to solve

Making a voice agent feel natural and reliable in production comes with some real technical headaches.

One of the first was speaker tracking. Both Twilio and OpenAI emit events about who is speaking, but interpreting those signals consistently in real time is tricky. We needed to know precisely whether the bot or the caller was talking at any given moment; otherwise, the AI might interrupt the user or miss what they said.

Conversation flow was another big challenge. A voice interface that sounds robotic is a fast way to frustrate callers, so we invested heavily in prompt engineering and tuning cadence, tone, and responsiveness. We wanted it to feel like a helpful conversation, not a phone menu.

Finally, we had to keep multiple live connections synchronized. Twilio streams, OpenAI responses, and ilert backend state all need to stay aligned. If any part drifts, context gets messy and the agent starts acting confused. Tight orchestration and careful state management were essential.

Context-aware conversations in practice

What makes the Voice Agent different from traditional IVR systems is that it combines intent recognition with optional context enrichment. At call start, it receives possible intents, gathers follow-up paths, and captures the caller’s number. If enrichment is enabled, it also learns what’s happening in ilert right now: whether there are open incidents, degraded services, or maintenance windows. That lets it respond based on reality instead of reading a static script, and route callers to the right path much faster.

Lessons learned so far

Beta testing taught us that interruption isn’t an edge case – it’s how people naturally talk on the phone. Letting callers interrupt the AI makes the experience smoother, but it also makes accurate speaker tracking even more important. The same tracking helps detect long silences so calls don’t run forever when nobody is speaking. We also reaffirmed that prompt engineering is essentially part of product design here: the voice needs to sound human while staying inside clear operational boundaries. And, unsurprisingly, multi-stream synchronization remains a core reliability requirement in any real-time voice system.

Building AI SRE: Our journey

Ali — Tue, 11 Nov 2025 15:03:20 +0000

Even with automation and observability, most on-call workflows still rely on human responders juggling dashboards, logs, and chat threads under pressure. It’s reactive, fragmented, and cognitively draining. At ilert, we set out to change that. Not by adding another dashboard, but by making incident response more agentic: intelligent systems that understand, recommend, and act safely in real-time.

In this article, we want to share how we are building an agentic incident response, what we've learned on the way, and the next steps.

By the way, if you haven’t heard of us — ilert is an AI-first incident management platform that helps engineering teams reduce downtime and improve MTTR.

This article was written by ilert engineer Tim. You can find the full version of it in the Engineering blog, where we regularly share our journey of building AI SRE.

We began our path to agentic incident response by designing an architecture focused on flexibility, scalability, and intelligent automation throughout the entire incident lifecycle.

Laying the groundwork

Hive: LLM Orchestration Layer

Hive is ilert’s backbone for AI-driven operations — a secure orchestration layer that manages multiple large language models for incident analysis, summaries, and contextual recommendations. It lets us route workloads to the best model for the job, maintain data privacy, and integrate new LLMs effortlessly as they emerge.

AI Voice Agent: Hands-free response

When responders can’t type, our AI voice agent becomes the interface — capturing spoken issues updates, turning them into structured alerts, and pulling fresh data from multiple sources. It bridges natural communication with automated precision.

The core: Model Context Protocol

The Model Context Protocol (MCP), originally developed by Anthropic, is a real-time system that connects operational data to the ilert AI SRE. It provides the structured context our agents need to act intelligently during incidents.

Why MCP? Traditional integrations often leave systems disconnected, forcing teams to manually correlate telemetry, logs, and infrastructure data. MCP eliminates these silos by automatically aggregating and structuring incident-relevant information in real time.

MCP collects data from monitoring tools, log aggregators, deployment pipelines, and infrastructure platforms, processes it within a secure, EU-compliant, multi-tenant architecture, and delivers only the essential insights to our agentic responders.

This ensures that:

Agents have real-time, granular incident awareness;
Data remains isolated, secure, and compliant;
Manual correlation and cognitive load are minimized;
Interactions with the ilert AI SRE agent are low-latency and context-rich.

So, MCP is a kind of neural layer connecting your observability stack, codebase, and infrastructure to our AI systems — keeping every action contextually accurate, relevant, and safe.

The ilert AI SRE: Turning alerts into agent-proposed actions

We built an end-to-end pipeline that turns monitoring signals into intelligent, actionable workflows to speed up incident resolution. When an alert is triggered, Event Flow (automated workflows to streamline processing, routing, and escalating events in ilert) applies rules and thresholds to notify the right teams instantly — cutting noise and delay.

At the same moment, the MCP enriches the alert by gathering and structuring telemetry, logs, deployment data, and infrastructure status from tools like Prometheus, Grafana, GitHub, and Kubernetes. This gives the ilert agent full situational awareness without any manual correlation.

With this context in place, the ilert AI SRE becomes an active participant in the incident, not just a notifier. It analyzes data in real time to propose root causes, remediation steps, and escalation paths. All surfaced in an interactive chat interface where responders can review, adjust, or safely execute actions on the spot.

What we learned along the way

Building and running agentic systems for real-world, mission-critical incident response has been an insightful journey. Here are a few things we’ve learned along the way:

Transparency builds trust. When agents act autonomously — collecting data, correlating signals, or even executing predefined actions — human-responders need to see what’s happening and why. Full visibility builds confidence. For high-impact actions, we let teams add approval steps, striking the right balance between speed and safety.
Context is everything. To avoid hallucinations or half-baked suggestions, we feed our agents rich, structured data through the MCP. This keeps every insight grounded in reality — and makes the agent feel more like a reliable teammate than a guessing machine.
Low latency matters. In an incident, seconds matter. We’ve optimized for speed with speculative tool calls and efficient data paths so responders get insights almost instantly. Less waiting, faster recovery.
Feedback makes it better. Every incident teaches something new. Built-in feedback loops help the system learn what works (and what doesn’t), so it becomes sharper and more helpful over time.
Safety first, always. Autonomous doesn’t mean out of control. By defining safe, scoped actions, the agent can fix certain issues on its own — with full rollback options if needed. That way, automation accelerates recovery without ever compromising reliability.