GraphQL platform engineering at XING

“Helped migrate registration/login from Perl to React and overhauled the settings app (GraphQL-aggregated) across a 60+ app platform.”

XING (NEW WORK SE) is a professional network with a platform made of 60+ separate applications, each maintained by its own feature team. Working at that scale changes the job: a single user-facing screen — like account settings — isn’t backed by one service, it sits on top of many, each owned by a different team with its own API. My work there was about making that complexity legible to the user and manageable for the engineers behind it.

It started, again, with a ramp-up bet

When I applied, XING was in the middle of migrating its frontend from Perl to React — and I had no React experience. The coding challenge I delivered during the interview was, quite literally, my own introduction to the framework: I learned React by building the thing they used to evaluate me. It was the same fast ramp-up bet that got me into web development in the first place, and it paid off again.

The settings app was a platform, not a screen

My first big project was to overhaul the user settings area. This landed right as GDPR was about to reshape how every product on the internet handled personal data, and XING was preparing with a redesign and stack migration of the settings app — so users could control how notifications reach them, download their personal data, and exercise the rest of what modern account settings have to offer.

The catch is what sits underneath. Every setting is saved by talking to a different API — usually a Ruby on Rails backend owned by a dedicated feature team. That made the settings app more of a platform than an interface: it had to integrate dozens of independently owned backends into one coherent surface.

Two decisions made that tractable:

• Code consistency from day one. We built strong consistency into the app from the start, deliberately — because the long-term goal was co-ownership, getting each feature team to maintain its own settings area later. Consistency was the precondition for teams being able to comply.
• A dedicated GraphQL aggregation layer. A team was dedicated to building the GraphQL layer that aggregated those APIs and returned exactly the data a given settings area needed — so the frontend could ask for one screen’s worth of data and let the graph fan out to the underlying services.

Platform-level thinking, on the frontend

Building a React SPA on top of all that forced platform-level thinking onto the frontend — concerns you can usually hand-wave in a smaller app became first-order:

• cache invalidation strategies across many independently changing backends;
• cookie and session handling;
• API design — shaping what the aggregation layer should expose;
• component architecture that stayed consistent enough for co-ownership;
• test infrastructure to keep all of it safe to change.

This was my first time building features at genuine B2C platform scale — a network with over 20 million registered users — where a decision on one screen has consequences across the whole product.

Registration, authentication, and Perl → React

My primary feature team owned registration and authentication — and migrating those apps was where I did some of my most hands-on work. I was a primary force in moving registration and login from Perl to React, which meant touching every part of the authentication process, and I implemented two-factor authentication along the way. Auth is unforgiving: it has to be correct, secure, and never break for real users mid-migration, which taught me another layer of web fundamentals on the go.

The organizational lesson

XING was also where I learned to navigate a large corporate engineering environment. Building a platform that spans 60+ teams is as much an organizational problem as a technical one: breaking down silos, advocating for my team’s interests, and negotiating resources and implementation direction with other teams. And simply being surrounded by excellent developers in a cross-functional team taught me to see the whole product-development process, not just the frontend slice of it.

What it set up

This is where I built the React + GraphQL foundation I later reached for when starting Loopy Demos on Gatsby — the same React-plus-GraphQL model, now under my own control end to end.