Vipani ERP

[ 01 ] · THE PROBLEM

An ERP gets judged on its slowest screen. Reporting workflows were running into slow scans, and everyday API calls were taking 450ms+, so the slow spots set how fast the whole system felt.

[ 02 ] · HOW IT FITS TOGETHER

Architecture

The React client calls the GraphQL Yoga API. Requests pass authentication and role checks, reach batched resolvers, and read from Redis, PostgreSQL or the OpenAI API.

[ 03 ] · WHAT I DECIDED

Key decisions

1. 01

   One GraphQL backbone, split into modules

   Inventory, HR and finance sit behind one GraphQL Yoga API, built from schemas, resolvers, queries and mutations that stay modular as the product grows.

2. 02

   Measure the query before touching it

   I profiled the slow reporting queries with EXPLAIN ANALYZE, then added composite B-tree indexes so the database stopped scanning where it should have been looking up.

3. 03

   Batch the reads, cache the repeats

   Query batching cut the number of database trips per request, and Redis caching took catalog lookups and sessions off the database for repeat reads.

4. 04

   Authentication that holds up

   JWT login with refresh-token rotation, RBAC middleware and request validation, plus central error handling and Winston logs across staging and production.

5. 05

   Tests next to the modules

   Automated unit and component tests with Vitest across ERP modules, so changes in one module did not quietly break another.

[ 04 ] · WHAT CAME OUT OF IT

Results

• ~50%Faster reporting queries, from ~800ms+ to under 400ms.
• ~50%Faster API responses, from ~450ms+ to ~225ms.
• Peak read traffic put less load on the database.
• AI-assisted operational report generation inside the same platform.