Schema design is important

GraphQL is a relatively newtechnology, 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

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.