As lead frontend engineer at Datatailr I owned the platform console end to end — 412 of 543 frontend commits (76%), about 37,650 lines of TypeScript across 301 files and 14 routed pages including the job scheduler, workflow runs, instance manager, and user/group manager.
When a fleet-scale dashboard got slow (issue #1297), I traced it to N+1 GraphQL fan-out and fixed it by writing four Postgres analytics views (442 lines of SQL) exposed through pg_graphql — collapsing the fan-out to one indexed view read per page. I built the DAG workflow viewer on xyflow with dagre auto-layout, viewport-culled rendering, and a 0.05–10× zoom range, and wired a dual codegen pipeline (GraphQL Codegen plus orval generating react-query hooks and Zod schemas from the OpenAPI spec) into the build.
The hard part
Moving aggregation into the database
A monitoring dashboard fanned out into dozens of GraphQL calls per page and crawled at fleet scale. Instead of caching around the symptom, I moved the aggregation into Postgres: four analytics views (442 lines of SQL) exposed through pg_graphql, so the client reads one indexed view per page instead of orchestrating N+1 round-trips. The page went from sluggish to instant, and the fix lived in the data layer where it belonged.
Highlights
- Authored 412 of 543 frontend commits (76%): 301 TypeScript files, ~37,650 lines, 14 routed pages.
- Cut a dashboard's GraphQL N+1 fan-out (issue #1297) to one indexed read by writing 4 Postgres analytics views (442 lines of SQL) exposed via pg_graphql.
- Built the DAG workflow visualization with dagre auto-layout over xyflow: custom node types, deferred layout, viewport-culled rendering, 0.05–10× zoom.
- Fixed a workspace double-start race (issue #1091) with an idempotent start guard, backoff state polling, and a health-probe redirect.
- Wired a dual codegen pipeline — GraphQL Codegen + orval (react-query hooks and Zod from OpenAPI) — into the build against live schemas.
Stack