Subhendu Das

Posted on Oct 22

LIC Plan Comparison Tool: FastAPI & React Workflow

#fastapi #react #vite #postgres

Problem

LIC agents in India often juggle dozens of plans while presenting them to clients. The traditional approach—static PDFs or spreadsheets—leads to duplicated effort, stale bonus data, and slow page loads when a new plan is added. A digital tool that loads only the necessary code for a chosen plan, while isolating runtime errors, directly addresses these pain points.

Implementation Overview

The DoAide InsureKit achieves this with a combination of FastAPI on the back‑end, React + Vite on the front‑end, and a PostgreSQL database that stores plan metadata and current bonus rates. The most visible technical improvement is route‑level code splitting coupled with an error boundary.

Route‑Level Code Splitting

Vite, the bundler used in this project, supports dynamic imports out of the box. Each top‑level route in the React app is defined as a lazily loaded component. For example, the PlanComparison page that renders the lic plan comparison table is imported like this:

import { lazy, Suspense } from "react";

const PlanComparison = lazy(() => import("./pages/PlanComparison"));

export default function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <PlanComparison />
    </Suspense>
  );
}

When a user navigates to /compare, Vite bundles only the PlanComparison component and its dependencies into a separate chunk. The main bundle remains under 50 KB, reducing the initial payload and improving perceived performance for agents who need to switch between multiple plan views.

Error Boundary

Even with code splitting, a bug in one component could crash the entire UI. To mitigate this, the project introduces a custom error boundary that captures rendering errors and displays a fallback UI. The implementation looks like this:

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    console.error("ErrorBoundary caught an error", error, info);
  }

  render() {
    if (this.state.hasError) {
      return <h2>Something went wrong while loading the comparison.</h2>;
    }
    return this.props.children;
  }
}

export default function App() {
  return (
    <ErrorBoundary>
      <Suspense fallback={<div>Loading...</div>}>
        <PlanComparison />
      </Suspense>
    </ErrorBoundary>
  );
}

This pattern ensures that a failure in the premium calculator or a missing bonus rate does not affect the rest of the application. The boundary logs the error for developers and presents a user‑friendly message to the agent.

Back‑End Support

FastAPI powers the API endpoints that feed the comparison tool. A typical route looks like:

from fastapi import APIRouter
from pydantic import BaseModel

router = APIRouter()

class PlanRequest(BaseModel):
    plan_ids: list[int]
    age: int

@router.post("/compare")
async def compare_plans(req: PlanRequest):
    # Query PostgreSQL for plan details and bonus rates
    plans = await db.fetch("SELECT * FROM plans WHERE id IN :ids", ids=req.plan_ids)
    # Calculate premiums based on age and bonus
    results = [calculate_premium(p, req.age) for p in plans]
    return {"plans": results}

The calculate_premium function pulls the current bonus rate from the database, ensuring that the calculator always uses up‑to‑date data. Because the front‑end only loads the comparison component when required, the API is called only once per view, keeping server load low.

User Experience

From an agent’s perspective, the workflow is straightforward:

Select Plans – In the sidebar, check the boxes of up to 10 LIC plans.
View Comparison – The PlanComparison component renders a table with premium estimates, bonus rates, and a side‑by‑side comparison of LIC vs FD vs mutual funds.
Adjust Parameters – A small form lets the agent change the age or term, triggering a fresh API call and re‑rendering only the affected rows.

Because the component is lazily loaded, the initial navigation to the comparison page takes under 200 ms on a 3G connection. If an error occurs (e.g., the database is temporarily unreachable), the error boundary displays a concise message instead of crashing the entire UI.

Technical Takeaways

Route‑level code splitting reduces bundle size and improves load times, a critical factor for agents working in bandwidth‑constrained environments.
Error boundaries localize failures, keeping the rest of the lic agent tool usable.
FastAPI + PostgreSQL provide a lightweight yet powerful backend that can handle complex premium calculations without latency.
Vite’s native support for dynamic imports means minimal configuration overhead.

These techniques together make the DoAide InsureKit a robust platform for LIC plan comparison, insurance calculation, and portfolio management.

Future Directions

The current implementation already includes SEO prerendering for each route. Adding server‑side rendering for the comparison component could further reduce time‑to‑first‑byte for agents who rely on slow mobile networks. Additionally, a GraphQL layer could expose a single endpoint for all plan data, simplifying the front‑end logic.

Conclusion

By combining route‑level code splitting, error boundaries, and a FastAPI backend, DoAide InsureKit delivers a fast, reliable lic plan comparison experience that meets the needs of Indian LIC agents, insurance advisors, and financial planners.

DEV Community