GraphQL Europe 2018 — A summary
Last week, myself and three other engineers from Sainsbury’s were given the opportunity to travel to Berlin to the second ever GraphQL Europe conference. We’re big fans of GraphQL, so of course we jumped at the chance.
The lineup looked fantastic, with varied topics and speakers. Lots of the big names in the GraphQL world were due to speak such as Facebook, Apollo, GitHub and Prisma, but there were also a bunch of speakers sharing their experience from smaller startups, agencies, and academia.
It was great to get to learn all about GraphQL from many different perspectives. There was something for everyone — from theoretical computer scientists to front-end engineers to teaching. I was particularly fascinated by the formalisation of GraphQL and an algorithm to enumerate how complex a query is. It was also great to see how other organisations are using GraphQL and overcoming similar challenges to ourselves, and also to hear from the people who make the tools we use every day.
Derek Kaye
The first thing that stuck out to me about the one-day conference was its format. Traditionally larger conferences have multiple tracks, with five or six speakers giving talks of about an hour in length. You have to pick the talks you’re most interested in, and there’s usually a break every two talks or so.
GraphQL Europe instead had a single track, with talks lasting either ten or twenty minutes. This meant that there were nineteen speakers on a single track — by far the most I’ve seen at any conference.
I loved this format. I think everyone was a little exhausted by the end of the day, but with time to decompress and digest I came away from Berlin feeling energised and excited about the future of GraphQL — both the technology, and the wonderful community that has grown up around it.
It’s been a week since the conference, and with some time to reflect I noticed a few themes throughout the day.
Schema design is important
GraphQL is a relatively new technology, and lots of the time we spent with it was trying to get into the right mindset. It’s really cool, then, to see the amount of best practices that are emerging from various sources. Leanne Shapton spent a fantastic 20 minutes going through the lessons that the Shopify team have learnt since adopting GraphQL. We could have avoided a lot of growing pains had we heard her a year ago! Specifically, her advice around paginating early, grouping related fields together and pushing complex calculations up to the server all really resonated with us.
There was a similar theme in Nicholas Van Wiggeren’s talk about adoption of GraphQL within GitHub — establishing best practices as early as possible made it much easier for them to get traction within the organisation, and remove the inevitable friction of a new technology as much as possible.
It was great to hear about some of the GitHub internals as well — the fact that their REST v3 API is now powered by GraphQL is a really cool inversion of the normal pattern you see with REST and GraphQL!
Type safety is pretty cool
The idea of type safety has always been a big part of GraphQL for me. The fact you get a strongly-typed contract between server and client is a core feature, and embedding that contract in the transport layer is a big part of what makes GraphQL such a game-changer.
However, I hadn’t realised what a big draw type safety was for a lot of people. Tyler Martinez and Johannes Schickling both about the idea of end-to-end type safety, with Scala or OCaml on the backend, TypeScript or Swift on the frontend, and GraphQL providing type safety at all levels. Tools like apollo-codegen can even translate between your schema definition and your types, giving you even more confidence in your code.
This idea really resonated with me, and it’s driven me to explore ideas like TypeScript (and apollo-codegen) much more in the future.
GraphQL architectures are varied
Quite a few speakers went into detail about their GraphQL architecture, and the different patterns that have started to emerge around how to build GraphQL systems.
The fact that we had two speakers, almost back to back, both advocating monoliths and talking about breaking them up, shows the variety and diversity of thought in this area.
Microservices
Lots of people are using GraphQL as a layer on top of their microservices. This has allowed them to slowly sub out some of the more painful parts of the infrastructure. As put by one of the speakers — if part of your estate is dying, GraphQL allows you to hide the bodies.
Sasha Solomon went into detail about the architecture that now powers Medium, and how it allowed them to migrate to a new client without slowing down product development. Medium has split their server architecture into three types of components — Schema, Fetchers, and Repositories. Fetchers provide a pure data fetching layer, pulling data from Medium’s existing business services over REST or gRPC, using Protobuffs. Repositories call out to Fetchers, and shape the data correctly for the Schema, which is derived from the Repositories. It looked like a really great pattern to adopt a GraphQL layer in front of your existing services.
Monoliths
Nick Schrock spoke a lot about monoliths, and how he sees the current move towards microservices as an overcorrection to some of the pain of traditional monoliths. The idea that microservices are a tool, rather than a goal, was received very warmly
One of the reasons people like GraphQL is because they miss the good parts of a monolith.
He also spoke about the idea of a GraphQL-Native application. He described GraphQL-Native as an integrated, cohesive, and flexible architecture, with a fat gateway between clients and services, that provides a source of truth for clients. Logic sits within the gateway, which calls out to capability-based services.
There were also some really interesting unconventional uses of the GraphQL Schema Definition Language (SDL), and both Arnaud Rinquin and Stephen Wan talked about their journey in getting more dynamic interactions with GraphQL servers, through the use of both subscriptions and Live Queries.
Diverse Languages
GraphQL has a reputation of being a front-end technology, and specifically associated with JavaScript. Lee Byron spoke about this being a consequence of how, and more importantly, where, GraphQL was announced — at a React conference.
However, I was really struck by the sheer diversity of languages and technology that was in use by speakers and attendees at the conference. I spoke to people using JavaScript, Scala, OCaml, Ruby, and even a team that had production services in Lua! There was also a great, whirlwind talk by Sara Viera about using GraphQL with Vue instead of React.
I think it’s one of the great strengths of GraphQL as a community, that it brings many disparate communities together to talk about how to build better products and services.
We should be investing in Tools
The GraphQL community has built some amazing tooling, and that trend looks to continue!
- The Prisma team announced a new GraphQL plugin for VSCode, which comes with full GraphQL syntax support, query autocompletion and schema validation.
- Peggy Rayzis announced a new release candidate of apollo-server-2.0 during her talk — this includes features such as subscriptions, error handling tools, schema stitching, and schema directives. It also supports Apollo-Engine as standard, and can run on a CDN edge via Cloudflare Workers!
However, Lee highlighted that tooling still isn’t in the place he anticipated when first putting his GraphQL secret master plan together.
A couple of people called out the need for a “Rails for GraphQL”, and the wish for more vertically integrated toolkits. Getting started with a client & server is still a bit awkward, so a more opinionated tool which can effectively scaffold a new application would be an awesome addition to the ecosystem.
Lots of successful GraphQL adoption
It was brilliant to see how many organisations had adopted GraphQL over the past year. There were lots of stories of successful migrations, both in a technical and organisational sense.
I particularly enjoyed Jira Vinyoopongphan’s talk about how to go about getting GraphQL adopted in your organisation — how to engage interested parties with inspiring demos, and the importance of making yourself available to support adoption.
Most successful adoption stories seemed to follow a similar pattern: one of incremental adoption. Rather than a full migration program, GraphQL allowed teams to add a gateway to their architecture, and then slowly substitute the services which backed that gateway with improved or new versions. This has been possible before, but the expressiveness and freedom that GraphQL provides with resolvers has made this seemingly a much nicer experience.
All in all, we had a fantastic time at GraphQL Europe. There was a brilliant line-up of speakers, a ton of interesting topics, and we got the chance to meet a load of great people in the GraphQL community. I’ll be looking forward to next year!
