Skip to content

GraphQL Contributor Days | December 2021

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

This is a recap of the December GraphQL Contributor Days, an event where maintainers and contributors came together to talk about all things current and upcoming in the GraphQL realm! Read on or rewatch the event here to see what these experts have to share, and see what they're using at companies such as Facebook, PayPal, Hasura, and Netflix.

Our hosts for this event were Dustin Goodman and Tanmai Gopal.

Panelists

Community Showcase & Updates

GraphQL Yoga (Uri Goldshtein)

GraphQL Yoga 2.0 has been in the works for the past few months, and it’s finally launched its alpha! This version is shipping with Envelop, and includes support for deferring streams, live queries, and the latest GraphiQL IDE.

RescriptRelay CLI (Gabriel Nordeborn)

A new feature has been added to the RescriptRelay CLI! This new command has the ability to go through your code and remove all unused fields and fragments from your GraphQL queries, which in turn helps prevent over-fetching in your application.

yarn rescript-relay-cli remove-unused-fields

GraphQL Learning

What can we do to support or easily onboard team members that may be new to GraphQL? What challenges do we face? Our panelists shared some of their favorite resources and methods that have worked for their teams, as well as brought up some great points about resources the community is still lacking.

The general consensus was that folks coming from REST can have trouble learning the GraphQL way of doing things. Things like introspection & HTTP 200 blanket responses can cause errors and introduce security risks that may be overlooked by those learning GraphQL for the first time.

Our panelists also agreed that there’s a need for concise resources outlining some of these common pitfalls, and there’s also a need for a simple, language-agnostic GraphQL starter package (think Create React App, but for GraphQL). Unfortunately, these resources don’t seem to exist just yet. However, our panelists did still have some great tips and resources to share for those trying to learn GraphQL.

  • Kyle Schrade had a couple suggestions that worked for his team:
    • Create internal documentation where you can keep track of answers to common questions.
    • Create a Codegen so that it’s easier for new team members to set up subgraphs.
  • Adhithi Rhavichandran shared a great Pluralsight course she co-authored on GraphQL API’s with Apollo. This is a great language-agnostic intro to GraphQL that talks about the differences between GraphQL and REST.
  • Jamie Barton created graphql.wtf to provide the GraphQL community with short, digestible videos on GraphQL concepts.

Authorization & Security

How can we handle authorization and security for our GraphQL API’s? What kinds of considerations need to be made? There is no “one size fits all” in handling authorization in GraphQL API’s.

With regards to where one should place their authorization logic, some argued for placing this logic at the resolver level (keeping auth logic close to business logic), while others wished to raise this logic up to a top layer to keep responsibilities separate. If the latter is your preference, Uri Goldshtein recommended GraphQL Authz for easily adding an authorization layer to your GraphQL API. This library is compatible with all modern GraphQL architectures as well.

As mentioned earlier, there were some differing ideas around whether or not to allow schema introspection. Though some saw it as a potential security risk, Joey Nenni argued that the benefits for developers can be enormous and provide a better user experience. If you've properly secured your API, there shouldn't be any significant risks involved with allowing schema introspection.

Federation

What are the benefits and challenges of federating? A pain point for Roy Derks is that underlying services need to be ready for federation. "It'd be nice if every schema could be federated with any schema," he said. Tanmai Gopal suggested that it'd be best to do configuration at the GraphQL entry point, rather than at the service level in order to tackle that problem.

What companies use federation, and how are they implementing it? Many of our panelists' companies are either actively using or planning to use Apollo Federation.

Tanmai Gopal, founder of Hasura, said that Hasura does federation in two steps - service to service federation, and data source to data source federation. At PayPal, Staff Engineer Joey Nenni shared that they're currently working on implementing the Apollo Federation spec.

Marc-André Giroux also shared that Netflix uses the Apollo Federation spec, though they have their own gateway built in Kotlin. The observability federation brings to their API, and the way federation fits within Netflix's microservice architecture works "beautifully" on his team. However, federating a monolith is perhaps not the best idea.

Lee Byron, co-creator of GraphQL, agreed and shared that Facebook has a different approach. "I think federation brings a lot of value, but at a lot of cost," he explained. Schema registries, query plans, and all of the other "stuff" that comes with federation can be a lot to manage.

"Facebook doesn’t use any of that ... instead they use a model ... where you have a single definition of your schema that exists at your gateway." - Lee Byron

Federation can be a great fit if your organization isn't a monolith and values team autonomy. "[At Facebook] team autonomy is an anti-pattern," Lee joked. Teams that value autonomy or that may not share a unified language, on the other hand, may find a lot of value in federating.

Other panelists agreed that company culture and team structure play a big part in determining whether to use a monolith or microservice structure, which can also determine whether or not federation is a good fit for your project. Culture can be very difficult to change, and may not even be possible.

"Regardless of the decision the net result is very similar. … However it is that we arrive at that conclusion, it doesn’t matter that much, and so we should choose the one that is easier for your organization." - Lee Byron

What's new at GraphQL Foundation?

  • The Working Group, which contributes changes to the GraphQL spec, is about to run a vote for the leaders of their technical steering committee. This steering committee will be responsible for overseeing the Working Group.

  • The GraphQL Foundation has a bunch of new members and sponsors, which has allowed them to launch a brand new community grant program in order to redistribute some of those funds and encourage community-driven development. You can find the grant program here!

  • There's a newly released cut of the GraphQL spec!

That's a Wrap!

GraphQL Contributor Days is always a great way to keep your ear to the ground on what's coming in the GraphQL ecosystem. This month's event provided some fascinating insight into how some of the top companies in the world are using GraphQL. If you'd like to watch the full event and hear our panelists dive deeper on some of these topics (and more), you can find it here!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Prefer email? hi@thisdot.co