Procurement League - Digital B2B commerce platform

Procurement League is a global B2B digital hub connecting procurement and supply chain professionals across buying, selling, hiring, and industry networking. The platform serves a community of 53,000+ members and handles a significant volume of real-time data - job listings, sourcing requests, forum discussions, vendor connections, and training content - all in one place.

The numbers visible on the live platform tell the story: 44,580 minutes of active engagement, 1.4M online impressions, and a 90% buyer success rate. Keeping a platform with that kind of activity fast and reliable under load is not a UI problem. It's a data architecture problem.

I was brought in at BJS Soft Solutions to revamp the frontend, restructure the data layer using GraphQL, and bring load times and caching up to production standards.

The platform had grown organically across multiple modules - job board, community forum, sourcing tools, training content - and the data layer hadn't kept up. Pages were slow to load because data was being fetched in ways that didn't account for the volume or complexity of what the platform was actually serving. Redundant API calls, no meaningful caching, and over-fetching were compounding each other.

The ask was to revamp the frontend using React.js and move the data layer to GraphQL - not just swap the syntax, but rethink how data was fetched, cached, and kept consistent across a platform where multiple modules share overlapping data.

The constraint that made this harder than a typical refactor: the platform was live with an active user base. Performance improvements had to ship without breaking what was already working.

The entry point needed to handle three distinct user types - buyers, sellers, and industry professionals - each with their own navigation paths and content priorities. The revamped homepage surfaces this clearly with dedicated CTAs and a stats section that pulls live platform metrics. Navigation covers six top-level sections with dropdown depth, all performant on first load.

The core of the revamp was moving from REST to GraphQL with Apollo Client. The immediate benefit was eliminating over-fetching - instead of pulling full objects and ignoring half the fields, queries now request exactly what each page needs. Apollo's normalized cache handles deduplication and keeps data consistent across components without redundant network calls.

Caching strategy was the part that required the most thought. Different data types needed different cache policies - job listings needed near-real-time freshness, while vendor profiles and forum topics could tolerate longer cache windows. Getting that right per query, rather than using one blanket policy, was what drove the 40% reduction in data load times.

The job board is one of the heaviest data surfaces on the platform. It shows 25+ live listings at a time, each with type, deadline, company, education requirement, experience level, and job description preview. Six filter dimensions operate simultaneously - Country, Job Level, Education, Category, Employment Type, and Skills - and results update without a full page reload.

Getting this right with GraphQL meant designing queries that could handle compound filter combinations cleanly, plus client-side filter state management that didn't cause unnecessary re-fetches when filter values changed. Time-based filters (Last 24 Hours, Last 7 Days, This Month, Last Month) layer on top of this and needed their own cache invalidation logic.

The forum is where the community actually lives. It has its own topic taxonomy - Strategic Sourcing, Category Management, Contracting, Purchasing, Payment, Biotech, CRO, Healthcare, and more - with tabbed views for What's Hot, What's New, Unanswered, My Discussions, RFQ, and Saved. Each discussion thread shows tags, author, engagement counts, and a content preview.

This module needed careful thought around data freshness. Forum content changes frequently and users expect near-real-time visibility of new posts. Apollo's cache update patterns - writing directly to the cache on new post creation rather than refetching the entire list - kept the UI responsive without hammering the server on every interaction.

40% reduction in data load times across all platform modules through GraphQL query optimization and Apollo caching

Live platform serving 53,000+ members across job board, community forum, sourcing, and training modules

44,580 minutes of active user engagement and 1.4M online impressions — platform metrics visible on the live homepage

90% buyer success rate maintained through improved data reliability and real-time update handling

Six-dimension simultaneous filtering on the job board without full page reloads

Eliminated redundant API calls through Apollo Client's normalized cache and query deduplication

Forum real-time updates handled via cache write patterns rather than full list refetches