GraphQL Europe 2018 — A summary

Chris Grice
Jun 25, 2018 · 7 min read
(Photo by Stefan Kunze on Unsplash)

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

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

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

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

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

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

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 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

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!

Sainsbury’s Tech Engineering

A dive into some of the engineering work done behind the…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store