Atlas is the fertilizer demand planning app inside the AeGIS monorepo at Pupuk Indonesia. I scaffolded its first version, moved the map to OpenLayers, and built the client-side demand formula engine with 52 unit tests. On the Go backend I made the overview queries date-bounded and coalesced.
- Year
- 2026
- Status
- In development
- Stack
- React 19, OpenLayers, Tailwind CSS v4, Rsbuild, Bun Workspaces, Turborepo, Biome, Recharts, Go Fiber v3, PostgreSQL
- Source
- Internal. Source is not public.
The story
Atlas is the fertilizer demand planning app in the AeGIS monorepo at Pupuk Indonesia Holding Company. Planners combine planting stages, dosage, and land area to estimate demand per region. When an assumption changed, they recalculated by hand.
I scaffolded the first version of the app and later moved its map from MapLibre to OpenLayers. The main piece is a formula engine that runs in the browser. It allocates demand across planting stages, applies land area overrides, and computes the difference from the baseline.
A formula editor store tracks each change. Because the engine runs client-side, the numbers update on each edit without a server call. To keep the math honest, the engine has 52 unit tests covering stage allocation, overrides, and float tolerance.
On the Go backend, I changed the overview queries from EXTRACT on year and month to date ranges, coalesced identical in-flight requests, and added a short cache. I also built the GeoMind workspace, where the AI assistant and the map share filters both ways. The monorepo, the Go service framework, and the Halo and Tango apps are my colleagues' work.
Scope
- who
- Aditya Vahlevy Nugraha, as one of three engineers on AeGIS. Aditya authored 349 frontend commits and 59 backend commits. The monorepo, Go backend, Halo, and Tango apps were built by colleagues.
- what
- The Atlas app: demand map, overview dashboard, formula editor, GeoMind assistant workspace, and data playground.
- when
- April to October 2026.
- where
- Internal planning tool at Pupuk Indonesia Holding Company.
- why
- Planners recalculated fertilizer demand by hand when dosage or land assumptions changed.
- how
- React 19 and OpenLayers in a Bun and Turborepo monorepo, with a Go Fiber v3 backend.
Problems solved
Problem
Changing a dosage or land area meant recalculating fertilizer demand by hand.
Change
Built a client-side formula engine for stage allocation, land overrides, and demand deltas, plus a formula editor store with change tracking (cef578a, aaa6844).
Result
52 unit tests pass with 86 assertions (bun test, formula-calc.test.ts). Planner time saved: Not measured.
Problem
Overview queries filtered with EXTRACT on year and month and ran again for identical concurrent requests.
Change
Replaced EXTRACT with month date bounds, coalesced in-flight requests, and added a 60 second cache (f123900).
Result
Covered by overview_test.go. Latency change: Not measured.
Before and after
| Measure | Before | After |
|---|---|---|
| Formula engine unit tests | 0 | 52 passingprojects/aegis/aegis-fe/apps/atlas/src/features/fdm/lib/formula-calc.test.ts, commit cef578a |
| Overview query filter | EXTRACT on year and month | Month date bounds, request coalescing, 60s cacheCommit f123900, projects/aegis/aegis-be/internal/domain/atlas/overview/overview_test.go |
| Map library | MapLibre GL | OpenLayersCommit 25636ba |
| Overview query latency | Not measured | Not measuredNo benchmark in the repositories |
My part
- Scaffolded the first version of the app, then named geodash (5412fc2).
- Migrated the map canvas from MapLibre to OpenLayers (25636ba).
- Built the formula engine with 52 unit tests and the formula editor store (cef578a, aaa6844).
- Built the GeoMind workspace with two-way sync between chat and map filters, and fixed stream payload parsing (2ce3701, a958140).
- Made overview queries date-bounded and coalesced, and added 5 headline insights (f123900, 94724bb).
- Built a tile proxy in front of the Martin tile server with HMAC token auth and a 1MB response cap (2d9fa97, 7372f32). Later removed it as unused (d54b217).
Platform scope
- Scaffolded the first version of the Atlas app (then geodash) in the AeGIS frontend monorepo.
- Migrated the map canvas from MapLibre GL to OpenLayers.
- Built a client-side fertilizer demand formula engine with stage allocation, land overrides, and demand deltas, covered by 52 unit tests.
- Built a formula editor store with derived change tracking.
- Built the GeoMind assistant workspace with two-way sync between chat and map filters, and fixed double-encoded stream payloads.
- Replaced EXTRACT-based overview filters with month date bounds, added in-flight request coalescing and a 60 second cache, and added 5 headline insights.
- Added a Graphic Walker playground for exploring demand data.
- Fixed backend panics and socket exhaustion in the Atlas service.
- Built a tile proxy for the Martin tile server with HMAC token auth, header forwarding, path traversal guard, and a 1MB response cap. Removed it later with other unused routes.
Decisions
- 01
Run the demand formula in the browser
Recalculation happens on each edit without a server round trip. Trade-off: the formula must be kept consistent with backend data, so it is pinned by 52 unit tests (cef578a).
- 02
Date bounds instead of EXTRACT
Range filters on the date column replace EXTRACT on year and month, which lets the database use an index. Concurrent identical requests share one query (f123900).
- 03
Remove unused code
Deleted uncalled market share routes, the tile proxy, and mock data once Atlas no longer used them (d54b217).
Hard parts
- Kept floating point results stable across stage redistribution, with tolerance checks in the formula tests.
- Kept chat filters and map filters in sync both ways in the GeoMind workspace without loops (2ce3701).
- Stopped duplicate overview queries under concurrent load with in-flight coalescing (f123900).
- Moved SNM feature deduplication to a Web Worker so tile processing does not block the main thread (snm-worker.ts).
Not measured yet
- Overview query latency before and after f123900.
- Time planners spend on a demand recalculation before and after the formula engine.
My own readiness estimate, self-assessed and not audited:
- tests
- 75/100
- docs
- 80/100
- quality
- 85/100
Commits
Commit hashes the claims on this page trace back to. The repositories are internal.
- 5412fc2
- 25636ba
- cef578a
- aaa6844
- 2ce3701
- f123900
- 94724bb
- 2d9fa97
- 7372f32
- 76d4382