# Scaling GraphQL development at Meetup

DevFeed: [Scaling GraphQL development at Meetup](<https://devfeed.tech/articles/scaling-graphql-development-at-meetup-23973.md>)

Original publisher: [Read original article](<https://medium.com/making-meetup/scaling-graphql-development-at-meetup-f290c8bbfad8?source=rss----6981e268ba45---4>)

Author: Doug Tangren

Published: 2024-02-05T22:11:32Z

Content type: article

Language: en

Sources: [Making Meetup - Medium](<https://devfeed.tech/sources/making-meetup-medium.md>)

Topics: [GraphQL](<https://devfeed.tech/topics/graphql.md>), [Development](<https://devfeed.tech/topics/development.md>), [maintenance](<https://devfeed.tech/topics/maintenance.md>)

Tags: [annotation-processor](<https://devfeed.tech/tags/annotation-processor.md>), [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [graphql](<https://devfeed.tech/tags/graphql.md>), [java](<https://devfeed.tech/tags/java.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

Meetup describes how it scaled GraphQL development by reducing maintenance and turnaround time for common GraphQL changes. The article examines GraphQL Java's DataFetcher and TypeRuntimeWiring model, and explains how repetitive schema wiring and file organization created complexity and testing difficulties.

## Source excerpt

Photo by Alev Takil on Unsplash At Meetup we're invested a great deal of our products technical strategy in GraphQL. For our core product API's we lean heavily on GraphQL Java for exactly that. Scaling can be defined in several ways. Typically people talk about scaling out servers to handle request load. In this post I'll take about scaling (in) development time, through the lens of reducing load placed on developers so they can make better use of their time. Over the years we've evolved our practices to optimize for reducing maintenance and faster turn around time for common GraphQL-oriented changes. This post outlines our current practices based on what we've learned. To start off, it's useful to introduce the vocabulary of GraphQL Java. A DataFetcher is the interface through which you fetch data for a given field or set of fields that a GraphQL client selects. GraphQL Java invokes these when a client selects their associated field based on a TypeRuntimeWiring which is what binds your code to your GraphQL schema. To some degree you can think of this like AWS Lambda where the trigger integration is GraphQL Java and your functions are DataFetchers. In fact we're not the first to think of that analogy . In our humble beginnings we started out with an approach that looked similar to the hello world example in the GraphQL docs: a single class with multiple runtime type wirings for various fields. This quickly grew unwieldy so we split that into multiple files which represented types and all of their respective fields. This worked for a while, but not before a few less than obvious issues started to creep in. Exposing a field meant writing the code that fetched the field's data and also the code required to wire that into the schema, and that became onerous. The latter was very repetitive, sometimes error prone, and the file that contained that grew slowly but surely into the same shape as our initial approach over time. It surfaced as nonessential complexity to new eng