XING.com is Germanys leading online business network and has been around for more than 15 years.
Architecturally it evolved from a single web application written in Perl into a complex distributed platform, written in several programming languages (`Perl`, `Ruby`, `Elixir`, `Scala` & `PHP`) and maintained by a large, distributed engineering team (~250 developers).
We’ve grown a lot over the recent years both organically and through acquisitions. Our company has evolved into a set of independently acting business units with different product offerings for different target groups and potentially competing annual goals. But we still share a technical foundation and have technical dependencies between our products. RESTful APIs helped us a lot to get where we are today, but in the recent years it became more and more obvious that our current setup produces a lot of friction in our product development efforts. We want and also have to be more efficient in that area in order to be properly setup for the future.
That’s where we started to look into alternative ways of building our products. When Facebook publicly presented GraphQL and talked about their motivation for it, some of the depicted challenges sounded awfully familiar. GraphQL looked like a perfect fit.
But there are a lot of questions that need to be answered on along the way. This talk will be about how we tried to skin the cat. We are going to cover • how we convinced our organisation that a major architectural change is worth the effort • how we started with the endevour • how we chose the target language / runtime • how exactly we retrofitted GraphQL onto our existing platform • what challenges we encountered and what kind of tradeoffs we had to make • how we approached operational aspects as monitoring, fault tolerance and resilience • last but not least, how we are rolling out this effort organizationally