As lead frontend engineer at Datatailr I owned the platform console end to end — the lead on its frontend across 14 routed pages: job scheduler, workflow runs, instance manager, and user/group manager.
When a fleet-scale dashboard crawled (issue #1297), I traced it to N+1 GraphQL fan-out and moved the work into the database — four Postgres analytics views (442 lines of SQL) exposed through pg_graphql, collapsing dozens of round-trips into one indexed read per page. I built the DAG workflow viewer on xyflow with dagre auto-layout, viewport-culled rendering, and 0.05–10× zoom, and wired a dual codegen pipeline (GraphQL Codegen + 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 pushed the aggregation into Postgres — four analytics views exposed through pg_graphql, so the client reads one indexed view per page instead of orchestrating N+1 round-trips. Sluggish to instant, and the fix lived in the data layer where it belonged.
Highlights
- Lead frontend across 14 routed pages — job scheduler, workflow runs, instance manager, and ACLs — owning 76% of the frontend.
- Cut a dashboard's GraphQL N+1 fan-out (#1297) to one indexed read with 4 Postgres analytics views over pg_graphql.
- Built the DAG workflow viewer on xyflow + dagre: custom node types, deferred layout, viewport-culled rendering, 0.05–10× zoom.
- Fixed a workspace double-start race (#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 + Zod from OpenAPI) — into the build against live schemas.
Stack