Agrilog — real-time agricultural platform
Full-stack work on interface performance and backend scalability for an agricultural-tech platform in Québec. Under NDA — stack and shape only.
TL;DR
- Full-stack contribution: front-end interface performance and backend scalability.
- GraphQL API over PostgreSQL as the system of record.
- ElasticSearch for search and aggregation at scale.
- TypeScript end to end (Node.js + Next.js).
- Under NDA — stack and shape of the work only, no client specifics.
Architecture
Generic architecture only — no proprietary detail. A GraphQL API fronts PostgreSQL for the system of record and ElasticSearch for search and aggregation; the Next.js client talks to one endpoint.
Problem
A data-heavy, real-time agricultural platform where two demands pull against each other: the interface has to stay responsive over large, frequently-changing datasets, while the backend has to scale search and aggregation over the same data without falling behind. Getting one right at the expense of the other isn't good enough — a fast UI over a backend that can't keep up, or a scalable backend behind a UI that stalls, both fail the user.
Approach
Full-stack work across a TypeScript stack: a GraphQL API over PostgreSQL for the system of record, with ElasticSearch alongside it for search and aggregation workloads that relational queries handle poorly at scale. On the front end, a Next.js interface with performance work focused on keeping large views responsive — measuring render and data-fetch cost, trimming what the client does per interaction, and shaping queries so the UI asks for exactly what it renders. Everything here is described generically; specifics of the platform stay with the client.
Deep dive
Front-end performance (generic)
Described in general terms only. The interface work centred on keeping large, frequently-updating views responsive: measuring where render and data-fetch time actually went, reducing per-interaction work on the client, and shaping GraphQL queries so a view fetches exactly what it paints rather than over- or under-fetching. The principle is stack-agnostic — measure first, cut the work the user is waiting on — and nothing here reflects client-specific screens or data.
Search & scale with ElasticSearch (generic)
Also described generically. PostgreSQL stays the system of record, but search and aggregation over a large dataset are workloads relational queries handle poorly past a certain size, so those route to ElasticSearch instead. Splitting responsibilities this way lets heavy read traffic scale independently of transactional writes — a standard pattern, presented here without any proprietary schema, query, or platform detail.
Holding both demands at once
The engineering theme, stated generally: a responsive interface and a backend that scales are usually optimised by different people pulling in different directions, and a platform only feels good when both are true at the same time. Working full-stack meant the same person could shape a GraphQL query for the backend's strengths and for the exact needs of the view rendering it — closing the gap where front-end and backend teams normally trade the problem back and forth. The specifics stay with the client; the approach — own the read path end to end, measure on both sides — is the transferable part.
Outcome
Under NDA. The contribution was full-stack: front-end interface performance and backend scalability for a Québec agricultural-tech platform (2024), on TypeScript, PostgreSQL, ElasticSearch, GraphQL, Node.js and Next.js. Only the shape of the work and the stack are described here; client specifics, proprietary detail and results are not disclosed.
Related
