GraphQL Adoption and Challenges: Community-Driven Insights from

StackOverflow Discussions
SALEH AMAREEN, Wayne State University, USA
OBED SOTO DECTOR, Domino’s, USA
ALI DADO, Domino’s, USA
AMIANGSHU BOSU, Wayne State University, USA
As organizations adopt GraphQL for API implementations, it is imperative to understand its challenges and the software
arXiv:2408.08363v1 [[Link]] 15 Aug 2024

community’s interests. To achieve this goal, we conducted a five-step mixed-method empirical analysis of 45K StackOverflow
questions and answers on GraphQL. In the first step, we derive a reference architecture for the GraphQL ecosystem with five
key layers. Second, we used topic modeling based on Latent Dirichlet Allocation (LDA) to automatically identify 14 topics and
47 subtopics. Third, we mapped discussion topics to architecture layers. Fourth, we manually investigate questions on each
topic and subtopics to provide additional insight to the GraphQL stakeholders. Finally, we study topic difficulty, popularity,
trends, and tradeoffs to provide insights into evolving community interests and challenges. Our results indicate that Client
and Server are the top two architectural layers attracting discussion on SO. While earlier discussions on SO focused on
building third-party applications consuming GraphQL APIs (i.e., API Integration) released by large organizations, recent
trends suggest more organizations implementing APIs using GraphQL servers. Due to difficulty and lack of well-defined
solutions, security remains a difficult and low-interest area. However, such a practice can lead to vulnerable APIs.
CCS Concepts: • Software and its engineering → Collaboration in software development; Integrated and visual
development environments; • Computing methodologies → Supervised learning.
Additional Key Words and Phrases: stackoverflow, topic modeling, graphql, API
ACM Reference Format:
Saleh Amareen, Obed Soto Dector, Ali Dado, and Amiangshu Bosu. 2024. GraphQL Adoption and Challenges: Community-
Driven Insights from StackOverflow Discussions. ACM Trans. Softw. Eng. Methodol. 33, 0, Article 0 ( 2024), 32 pages. https:
//[Link]/10.1145/[Link]

1 INTRODUCTION
In 2012, Facebook developed GraphQL, a query language and an application programming interface (API) for
web-based client-server architectures. Facebook had internally utilized GraphQL and continued evolving its
formal specification before finally open-sourcing it and releasing its specification and implementation to the
public in 2015. Facebook then transferred GraphQL to the non-profit GraphQL Foundation in late 2018. GraphQL
has gained a rapid adoption momentum in recent years, especially because it provides a technology paradigm
that is either alternative or additional to existing web protocols such as Representational State Transfer (REST)
Authors’ addresses: Saleh Amareen, [Link]@[Link], Wayne State University, 42 W Warren Ave, Detroit, Michigan, USA, 48202;
Obed Soto Dector, [Link]@[Link], Domino’s, 30 Frank Lloyd Wright Dr, Ann Arbor, Michigan, USA, 48106; Ali Dado, ali.
dado@[Link], Domino’s, 30 Frank Lloyd Wright Dr, Ann Arbor, Michigan, USA, 48106; Amiangshu Bosu, [Link]@[Link],
Wayne State University, 42 W Warren Ave, Detroit, Michigan, USA, 48202.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first
page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy
otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
permissions@[Link].
© 2024 Association for Computing Machinery.
1049-331X/2024/0-ART0 $15.00
[Link]

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:2 • Amareen et al.

5000

0.7
Ratio of unanswered questions
4000

0.6
Total number of questions

0.5
3000

0.4
2000

0.3
0.2
1000

0.1
0.0
0

2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022

Year Year

(a) Total number of GraphQL-related questions on the Stack- (b) Ratio of GraphQL-related questions without accepted
Overflow website per year, a higher number indicates grow- answers on the StackOverflow per year. A higher number
ing popularity. indicates growing difficulty.

Fig. 1. Questions and answers on StackOverflow over with #graphql tag over the years.

and Simple Object Access Protocol (SOAP) [34]. While the latter protocols dominated the industry for the past
decade, GraphQL has recently been increasingly adopted by major software companies such as Shopify, Amazon,
Pinterest, Netflix, and Twitter [34, 43, 61]. A recent Gartner report predicts that at least 50% of enterprises will be
utilizing GraphQL in production by 2025, which stood at 10% in 2021 [37].
One of the most prevalent properties of GraphQL is that clients can form type-safe GraphQL-like queries
or mutations that declaratively and precisely specify the data they require in a single call. This feature allows
clients to avoid issues commonly referred to as over-fetching and under-fetching that developers encounter while
using legacy protocols such as REST. Over-fetching occurs when responses of REST API calls include more data
than clients require. On the contrary, under-fetching occurs when existing APIs provide less data than clients
require, forcing clients to perform multiple calls to aggregate all necessary data. Over and under-fetching of data
represents a sub-optimal utilization of resources.
Although many organizations have increasingly adopted GraphQL, developers encounter numerous challenges
due to technical complexities and inadequate resources. One of the key support mechanisms for GraphQL
developers is StackOverflow (SO), which is a well-known knowledge-based website and part of the StackExchange
(SE) network [20]. SO moderates many posts that software professionals and enthusiasts discuss in the form of
questions and answers (Q&As) regarding various programming topics. A systematic analysis of GraphQL-related
questions will help the GraphQL community, including developers, told designers, and researchers, identify areas
requiring support and effort.
Motivating preliminary analysis: Before committing to a full-scale investigation, we conducted a preliminary
study with an SO data dump from December 2022 with the posts with the most prevalent GraphQL tag (i.e.,
#graphql). Figure 1a shows that software developers’ total number of questions on SO increased annually between
2012 and 2019. Since the number of questions has steadily fluctuated between 4K and 5K per year, this finding
reinforces previous research work that GraphQL continues to gain momentum and indicates that developers
continue to encounter challenges that require further assistance from the GraphQL community. Our second
finding, represented in Figure 1b, shows that the ratio of unanswered questions (i.e., questions with no accepted
answers) has been steadily increasing from 25% since its public release in 2015 to 74% in 2022. Such a finding
indicates the increasing difficulty of the GraphQL domain in the GraphQL community. Sri et al. [61] confirms such

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:3

difficulty of GraphQL in their recent study, which surveyed 38 Github employees who expressed that GraphQL
was challenging to learn, time-consuming with limited knowledge-base resources, especially when compared to
mature protocols such as REST. Moreover, the GraphQL domain is vast with programming-language-specific
implementations, libraries, frameworks, tools, IDEs, APIs, platforms, and documentation [10]. It is unknown
whether such breadth may leave GraphQL developers, software organizations, researchers, and educators prone
to several challenges, especially for newcomers. Therefore, it is incumbent to aid the GraphQL community in
understanding the difficulties, popularity, and trends of the various GraphQL topics because such understanding
will help its stakeholders make informed decisions, identify opportune research areas, and guide where they
should focus their time and efforts.
Objective and approach: This paper aims to help the GraphQL community of practitioners, researchers, and
educators understand the architecture, interest, challenges, and trends of topics within the GraphQL ecosystem
based on software developer discussions on StackOverflow [19]. To achieve this goal, we conducted a five-step
mixed-method empirical analysis of 45K StackOverflow questions and answers on GraphQL. In the first step,
we derive a reference architecture for the GraphQL ecosystem with five key layers based on two well-known
GraphQL implementations. Second, we used topic modeling based on Latent Dirichlet Allocation (LDA) to
automatically identify 14 topics and 47 subtopics. LDA has been the de-facto standard in the software engineering
(SE) discipline to analyze SO data [28, 60, 63]. Numerous research works have conducted LDA-based empirical
studies to analyze software developer discussions obtained from the stack exchange websites aiming to investigate
domains such as big data [28], security [65], blockchain [63], mobile development [56], concurrency [23], code
refactoring [51], Open-Source licensing [50] and internet of things (IoT) [60]. However, no prior research has
analyzed developer discussions in the GraphQL domain. Third, we mapped discussion topics to architecture
layers. Fourth, we manually investigate questions on each topic and subtopics to provide additional insight to the
GraphQL stakeholders. Finally, we study topic difficulty, popularity, trends, and tradeoffs to provide insights into
evolving community interests and challenges.
Contribution: The primary contributions of this study are as follows.
(1) An empirical analysis of 45,554 GraphQL-related questions and answers on StackOverflow.
(2) A reference architecture for the GraphQL ecosystem using two popular GraphQL implementations. The
architecture includes GraphQL client and server and describes their respective layers and components.
(3) A quantitative empirical study on the obtained GraphQL posts using topic modeling.
(4) A mapping the GraphQL topics to their appropriate architecture layers and components of our derived
reference architecture of the GraphQL ecosystem.
(5) A new approach to build multi-level topic hierarchy.
(6) An empirical characterization of the discovered GraphQL topics, their difficulty, popularity, tradeoffs, and
evolution.
(7) A set of implications and recommendations for the various GraphQL stakeholders.
(8) To facilitate replication and/or extension of this work by future researchers, we make our dataset publicly
available [26]1 .

Organization: The remainder of this paper is organized as follows. Section 2 provides a brief introduction to
GraphQL and discusses related work. Section 3 introduces the five research questions of this study. We elaborate
on our research methodology in Section 4. Section 5 details the results of this study. Section 6 discusses our
results and suggests recommendations for the various GraphQL stakeholders. We present threats that impact the
validity of our work in Section 7 before concluding in Section 8.

1 [Link]

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 0:4 • Amareen et al.

2 BACKGROUND
The following subsections provide a brief overview of GraphQL core concepts, research work on GraphQL, and
software engineering studies on topic modeling.

2.1 GraphQL
To comprehend GraphQL, we need to understand the following four core concepts.
1 # Definition of a type called ' User '
2 type User {
3 id : ID ! # A non - nullable unique identifier for the user
4 name : String ! # A non - nullable name of the user
5 email : String # The email of the user , can be null
6 }
7
8 # Definition of a query type to fetch data
9 type Query {
10 # A query to get a user by their ID
11 user ( id : ID !) : User
12 }
Listing 1. A Simple GraphQL Schema

1. GraphQL schema: A GraphQL schema is a blueprint that defines the data structure in a GraphQL API. It
outlines the types of data that can be queried, the relationships between those types, and the operations (queries,
mutations, and subscriptions) that can be performed. Listing 1 shows an example GraphQL schema.
2. GraphQL Query language (GQL): GQL is used to interact with a GraphQL API. It allows clients to request
exactly the data they need, and nothing more, in a structured and predictable way. This language is used to
construct queries, mutations, and subscriptions to interact with the API. Queries let clients retrieve data from the
server, mutations support data modification, and subscriptions enable clients to subscribe to real-time events
from a server. Listing 2 shows an example GraphQL query for the above schema.
1 # Query to fetch email address of the user with a specific id
2 {
3 user ( id : " 1 " ) {
4 email
5 }
6 }
Listing 2. GraphQL query

3. GraphQL Resolvers: GraphQL resolvers are functions on the server side to fulfill the runtime execution of client
requests to fetch, modify, or subscribe to resources. Resolvers may integrate with various data sources such as
databases, REST services, or other APIs.
4. GraphQL Lifecycle: The lifecycle of a GraphQL request begins when a client sends a query, mutation, or
subscription to a GraphQL server endpoint. The server then validates the request against its schema. If the request
is invalid, the server returns an error and does not execute the operation. If the request is valid, the server maps it
and its nested fields to their corresponding resolvers for execution. Each resolver processes its part of the request
and passes it down to the next level of resolvers until all requested fields have been handled. Finally, the resolver
returns the data to the GraphQL endpoint, which sends the response back to the client, typically in JSON format.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:5

2.2 GraphQL Studies

This section focuses on prior academic research on the GraphQL language specification, comparative studies
that focus on GraphQL vs. REST and migration paths, testing, and solutions proposed to address the challenges
software developers face while learning, using, or adopting GraphQL. Harting and Perez conducted one of the
earliest works to provide an initial formal definition of the GraphQL language [42]. The authors later followed up
with a second work [43] where they reported that the problem of evaluating the complexity of GraphQL queries
is nondeterministic logarithmic space (NL). While Harting and Perez utilized query normalization to work with
simpler semantics and were able to produce their GraphQL query complexity results, they did not provide a
normalization procedure. To address that, Tomas et al. proposed a mechanized formalization of GraphQL, which
they implemented in CoQ proof assistant and named it GraphCoQL. Their work proposed and formally proved a
normalization algorithm for Harting and Perez’s query transformations and interpretations and proved them
correct [38]. Gleison et al. conducted a literature review paper to characterize the advantages and disadvantages
of GraphQL in the existing literature [33]. In the same work, the authors employed the literature review results
to assess the practicality of migrating from REST to GraphQL on seven systems. They showed GraphQL could
significantly reduce the number of API calls and the number of fields in the returned JSON document and,
therefore, reduce the overall returned payload size in bytes. Sri et al. conducted a qualitative and quantitative
empirical study to explore the replaceability of REST with GraphQL in the future [61]. They surveyed 38 Github
employees to understand the advantages and disadvantages of both protocols and used metrics such as efficiency
and application feasibility to provide proper recommendations. They reported several key findings regarding
the challenges faced by software developers while adopting GraphQL, such as its difficulty in learning, time
consumption, and limited resources. They reported both protocols had their benefits and weaknesses.
On the other hand, a controlled experiment by Brito and Valente with 22 students found client-side application
integration with a GraphQL API easier than with REST [34]. They compared the implementation of remote service
queries using REST and GraphQL. They found that GraphQL required less effort, with a median implementation
time of 6 minutes compared to 9 minutes for REST. Additionally, implementing REST queries became more
challenging with complex endpoints and multiple parameters. Participants without experience found GraphQL
easier to implement and understand [34]. Wittern et al.’s empirical investigation of over 8K GraphQL schemas
mined from GitHub suggests that most APIs have security issues that can be exploited using complex queries [64].
For GraphQL testing, Asma et al. recently proposed a white-box testing framework to automate GraphQL testing
employing code generation that is based on evolutionary search [31]. The work aimed to maximize code coverage
and improved it by up to +55.53%. While other GraphQL automation testing research works had previously
existed (e.g., automation based on deviation testing [62] and property-based testing [46]), they had limitations in
terms of their inability to analyze byte-code. Patrick et al. proposed a non-intrusive and technology-independent
GraphQL federation [58] to address the shortcomings of the most popular Apollo federation implementation [13].
Their work employed domain-specific language (DSL) traceability links to describe and consolidate multiple and
possibly conflicting GraphQL schema. The authors provided a proof-of-concept implementation and a qualitative
comparison of their features compared to the Apollo Federation. Another recent direction focuses on assessing
execution strategies and costs of GraphQL queries [35, 47, 55].

2.3 Topic Modeling in Software Engineering

Many prior studies have used LDA-based topic modeling to analyze questions and answers on StackExchange and
StackOverflow [28, 50, 56, 60, 63, 65]. Barua et. al. conducted the first study in this direction using a StackOverflow
data dump from September 2010 [30]. However, with the growing popularity of StackOverflow and its sister sites,
subsequent studies have focused on specific areas by filtering questions using #tags. For example, Christoffer
and Emad analyzed 13 million mobile developer discussions on StackOverflow regarding iOS, Android, and

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:6 • Amareen et al.

Windows phone platforms to investigate difficult and popular mobile development topics [56]. Bajaj et al. [29]
presented a study to understand challenges and misconceptions web developers commonly encounter. Mehdi et
al. [28] developed a topic hierarchy to understand big data-related discussions [28]. Panichella et al. [49] proposed
a variation of LDA that utilized a genetic algorithm (LDA-GA) aiming to cluster topics optimally. Yang et al.
studied security-related StackOverflow posts utilizing LDA-GA [65]. Other studies in this area include software
refactoring [51], IoT [60], web servers [44], web browsers [40], blockchain [63], Open Source licenses [50],
AutoML toolkits [24], DevOps challenges [59], low code software development [25], platforms [25], and new
programming languages [36].
Novelty: This work differs from prior works in three key aspects. First, we focus on GraphQL, an emerging
technology expected to see rapid adoption among enterprises [37]. Hence, understanding the challenges and
needs of the GraphQL community is necessary to assist those adopters. To our knowledge, this analysis is
currently missing. Second, we develop a reference architecture of the GraphQL ecosystem and map discussion
topics on SO to these layers. Finally, we utilize a new approach to build a topic hierarchy model to identify
discussion sub-topics and present a three-level hierarchy of discussion areas.

3 RESEARCH QUESTIONS
This section introduces the five research questions driving this study with a brief motivation for each.
(RQ1) How can we define a referenced architecture of the current GraphQL ecosystem?
Motivation: The wide spectrum of the GraphQL ecosystem contains an immense amount of documentation.
Moreover, the abundance of technology stacks, programming-language implementations, frameworks, libraries,
development tools, domain terms, and documentation complicates software developers’ learning process. For
example, the following SO post shows how current documentation confuses a software developer: "...I came across
various terms associated with React - Flux, Redux, Relay, GraphQL...and am confused as to which architecture to
invest time and effort in learning and implementing..." [𝑄 36772960 ]. Another example is this SO post title: "is there
an apollo graphl site official (apollo client , apollo server), what is the correct name?" [𝑄 45647122 ]. We aim to define
a reference architecture for the current GraphQL ecosystem to help improve the learning curve, especially for
newcomers to GraphQL.
(RQ2) What do GraphQL developers discuss on StackOverflow?
Motivation: Identification of discussion topics can help GraphQL stakeholders, such as its namesake foundation
or its tool builders, understand common challenges practitioners encounter. These insights can assist them in
pinpointing recurring problems needing improved design, documentation, FAQs, or tutorials. Moreover, these
insights can help identify features or improvements most relevant to users and guide the development roadmap.
(RQ3) How can we organize GraphQL discussions on StackOverflow into a hierarchy of topics?
Motivation: Each primary discussion area may have several sub-areas. For example, discussions on a particular
tool may be divided into deployment, usage challenges, or integration issues. We aim to provide a finer-grained
analysis with a multi-level topic hierarchy to better understand each area.
(RQ4) How did GraphQL discussion topics on StackOverflow evolve?
Motivation: By analyzing discussion trends over time, we can observe how the challenges and interests around
GraphQL evolve. This insight will allow the community to focus on current issues rather than outdated or less
relevant topics. Moreover, the emergence of new discussions can highlight innovative uses of GraphQL, new
patterns, or integrations that might not have been considered before.
(RQ5) What are the difficulty and popularity of various GraphQL topics?

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:7

Motivation: This analysis will identify areas where the GraphQL community has better support and where it
lags. These insights can guide framework builders to prioritize new features or improvements based on what
users are increasingly asking about or struggling with.

4 RESEARCH METHODOLOGY
The following subsections detail our research methodology for deriving current GraphQL ecosystem reference
architecture, identifying discussion topics from the SO data dump, assigning names to topics, and mapping each
topic to architecture layers.

4.1 Deriving Reference Architecture of current GraphQL Ecosystem

GraphQL ecosystem documentation comes from various sources. The GraphQL language specification [21]
is the primary documentation source for GraphQL building blocks that various GraphQL implementations
comply with, whereas Apollo [2] represents the reference GraphQL implementation for both GraphQL client and
server. Additionally, the GraphQL specification is (by design) agnostic of the underlying programming language.
Therefore, libraries, frameworks, and various implementations across programming languages (e.g., Java, .Net,
Python, and Javascript) have their documentation. Moreover, since GraphQL emerged, software organizations
have offered GraphQL APIs in parallel or as alternatives to legacy RESTful APIs. Github, GitLab, Yelp, and Shopify
are a few examples of APIs that do so. Lastly, there are currently many third-party vendor platforms that aim to
provide a SaaS GraphQL experience, such as Amazon AppSync [1], Hasura [11], Prisma [15] and Gatsby [6]. Our
approach is motivated by reference architecture definition approaches from prior works [40, 44, 63] and is based
on the following two steps.
(1) Derive a conceptual Architecture: First, we derive a conceptual architecture utilizing the available GraphQL
documentation as well as the domain knowledge of the author. The list of authors includes three members,
each with more than five years of professional experience developing and maintaining large-scale enterprise
GraphQL deployments. Subsequently, we reverse engineer the source code of two GraphQL implementations
to refine our conceptual architecture and produce two concrete GraphQL architectures. The source-code
implementations we choose are, namely, Apollo GraphQL [2] and the Domain Graph Service (DGS)
framework by Netflix [4]. We selected these two since Apollo is the reference GraphQL implementation,
whereas DGS is a Java implementation popular for enterprise microservices. Moreover, both Apollo and
DGS provide client and server GraphQL implementations.
(2) Component definition: In this step, we define the responsibilities of each component and detail their
relationships. Three of the authors worked together in this step. Disagreements arising during this step
were resolved by looking into various relevant sources such as documentation, source code, and usage.
Fig 4 shows our proposed architecture. Section 5 details all architecture layers and components of the
current GraphQL ecosystem.

4.2 Topic Modeling

Following previous work [23, 28, 56, 60, 63, 65], we perform topic modeling, specifically LDA, to study the
GraphQL dataset we obtained from SO and identify the various GraphQL discussion topics. The following steps
detail how we perform LDA.
4.2.1 Importing StackOverflow Data Dump. SO is a knowledge-based online website serving as a platform for
software professionals and enthusiasts to discuss programming topics through questions and answers (Q&As).
Users of SO can ask questions, search for discussions about a certain topic, view discussions, search for specific
tags, provide answers, accept answers, and vote (up or down) for answers. As of June 2024, it contains 24 million
questions, 36 million answers, and 25 million users [20]. Therefore, SO represents a great source of real-world

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:8 • Amareen et al.

software developer discussions to the extent that analyzing such a knowledge-based website could provide key
insights to the relevant stakeholders of the respective domain communities, especially software practitioners.
To obtain the SO dataset, we download the December 2022 SO data dump and import the XML files into a
relational MySQL database to facilitate query and analysis. The datasets for all the StackExchange sites are publicly
available in the Internet Archive under the Creative Common License [18]. Each dataset contains seven XML
documents (i.e., i) [Link], ii) [Link], iii) [Link], iv) post_history.xml, v) post_links.xml,
vi) [Link], vii) [Link], and viii) [Link]). The [Link] file is what we are mainly interested in
analyzing since that is where the developers’ questions and answers data resides. Each post contains the following
key data. Id represents a unique identifier of a given post. PostTypeId is a classifier to help indicate whether a
given post is either a question or an answer. Title represents the subject of the post, whereas Body contains the
developer’s description of their post. AnswerCount keeps track of how many answers the developer community
has provided for a particular question. At the same time, ViewCount represents the number of times a given post
has been viewed. AcceptedAnswerId is an identifier for the accepted answer for a given question and is set to
null for answers.

4.2.2 Identifying GraphQL tags. Once we have obtained and formatted the dataset, we filter it based on a tagset
derived from a similar approach used in prior studies [23, 28, 60]. This approach starts with an initial set of
four tags (𝑇𝑖𝑛𝑖𝑡𝑖𝑎𝑙 ). Then, we identify tags that co-occur (𝑇𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑒 ) with these initial tags on SO. Finally, we
conducted an empirical study using two metrics defined in prior studies [23, 28, 56, 60] to identify an additional 56
relevant tags from the 𝑇𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑒 set. Our final set includes 60 tags (𝑇𝑓 𝑖𝑛𝑎𝑙 ). We detail our approach to identifying
GraphQL-related tags in the following.
(1) Initial tags: We started with graphql as the seed tag. We manually inspected the related tags listed on SO’s
tag description page ( [Link] and identified three additional
tags for our initial set, which are apollo, apollo-client, and apollo-server. Hence, 𝑇𝑖𝑛𝑖𝑡𝑖𝑎𝑙 includes
four tags.
(2) Identify candidate tags: We search the SO data dump (D) to identify a total of 21,137 questions (P) that
include at least one of the four initial tags. Next, we construct a set of candidate tags (𝑇𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑒 ) by extracting
tags of questions in P. This step found a total of 2,534 candidate tags.
(3) Prepare final set of tags: We use the two metrics, significance (𝜇) and relevance ( 𝜈) used in prior studies [23,
28, 56, 60] to identify highly relevant tags. For a tag (t), these two metrics are measured as follows.
# 𝑜 𝑓 𝑄𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠 𝑤𝑖𝑡ℎ 𝑡𝑎𝑔 𝑡 𝑖𝑛 P
Significance, 𝜇 (t) =
# 𝑜 𝑓 𝑄𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠 𝑤𝑖𝑡ℎ 𝑡𝑎𝑔 𝑡 𝑖𝑛 D
# 𝑜 𝑓 𝑄𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠 𝑤𝑖𝑡ℎ 𝑡𝑎𝑔 𝑡 𝑖𝑛 P
Relevance, 𝜈 (t) =
# 𝑜 𝑓 𝑄𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠 𝑖𝑛 P
We computed 𝜇 and 𝜈 for all the 2,534 candidate tags. A tag 𝑡 is significantly relevant to the graphql if 𝜇 (t)
and 𝜈(t) are higher than some empirically determined thresholds. To identify an optimal threshold pair,
we conduct an empirical study. This step identifies a tag subset based on a value pair. Then, we manually
inspect each tag to determine whether it is relevant to graphql by examining its description and recent
questions listed on SO’s tag description page. For a pair (𝛼, 𝛽), we also measure precision, which is defined
as follows:
# 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜 𝑓 𝑟𝑒𝑙𝑒𝑣𝑒𝑛𝑡 𝑡𝑎𝑔𝑠
Precision (𝛼, 𝛽) =
# 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜 𝑓 𝑡𝑎𝑔𝑠 𝑠𝑒𝑙𝑒𝑐𝑡𝑒𝑑 𝑏𝑎𝑠𝑒𝑑 𝑜𝑛 ( 𝜇 = 𝛼 & 𝜈 = 𝛽)
While setting higher threshold values yields higher precisions, we may miss some relevant tags. On the other
hand, lowering thresholds decreases precision. Therefore, similar to prior SO studies, we experimented with
a total of 49 combinations of (𝜇, 𝜈) from {0.01, 0.05, 0.1, 0.15, 0.2, 0.25, 0.3} × {0.001, 0.005, 0.01, 0.015, 0.02, 0.025, 0.03}.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:9

We found (0.2, 0.001) providing the set of relevant tags with a precision score of 96.7%. These threshold
values are similar to the ones used in prior studies [23, 28, 56, 60]. We consider this threshold pair optimal
since changing either of the values significantly lowers precisions or missing relevant tags.
At the end of these steps, we identified an additional 56 graphql-related tags. Table 1 shows 60 tags belonging
to 𝑇𝑓 𝑖𝑛𝑎𝑙 . We also manually grouped the tags into five categories.

Table 1. A categorization of all 60 tags we identified to filter the SO data dump to only include GraphQL posts.

GraphQL Tag Category GraphQL Tag Set

GraphQL Specification (4)graphql, graphql-mutation, graphql-schema, graphql-subscriptions
GraphQL reference imple- apollo, apollostack, apollo-client, apollo-android, apollo-angular, apollo-boost,
mentation (13) apollo-cache-inmemory, apollo-federation, apollo-ios, apollo-server, vue-apollo,
react-apollo, react-apollo-hooks
GraphQL programming- graphql-js, graphql-java, graphql-ruby, graphql-php, graphql-dotnet, graphql-go,
language implementations graphene-django, graphene-python
(8)
GraphQL Tools & Frame- absinthe, aws-appsync, ariadne-graphql, dgraph, gatsby, gatsby-image, gqlgen,
works (34) grandstack, graphcool, express-graphql, prisma-graphql, typegraphql, graphql-
tools, graphiql, graphql-codegen, graphql-spqr, hasura, hotchocolate, laravel-
lighthouse, netflix-dgs, nexus-prisma, postgraphile, prisma, [Link], react-relay,
relay, relayjs, relaymodern, sangria, wp-graphql, graphql-playground, neo4j-
graphql-js, graphql-tag, urql
GraphQL APIs (1) github-graphql

4.2.3 Identifying GraphQL related posts. We searched our SO dump for all the posts with at least one of the 60
tags from 𝑇𝑓 𝑖𝑛𝑎𝑙 and obtained 32,095 questions. Our search of the SO dump also found 31,195 answers to those
questions. However, only 38.3% of those answers are marked as ‘Accepted.’ Following the recommendations of
prior works [23, 28, 56, 60], we only consider questions and accepted answers since unaccepted answers may
include noises. Therefore, our topic modeling dataset includes 44,060 posts (32,095 questions and 11,965 accepted
answers).
4.2.4 Text preprocessing. Before applying LDA to identify topics, we follow a nine-step preprocessing approach
on posts to clean data. The following list describes our preprocessing steps.
(1) Conversion to lowercase: We convert all the words to lowercase to ensure that the LDA model does not
consider the capitalization of a word as a separate word from its lower-case counterpart.
(2) HTML removal: We remove all the HTML tags since those are not relevant to discussion topics.
(3) URL removal: Both questions and answers may include URL references (e.g., API reference) supporting the
post. Since URLs do not communicate discussion topics, we remove all URLs from each text.
(4) Stopword removal: Since stopwords (usually non-semantic words such as articles, prepositions, conjunctions,
and pronouns) are irrelevant to identifying topics, we remove all stopwords from each text.
(5) Domain-specific term removal: We exclude GraphQL domain-specific terms (e.g., "graphqL", "apollo", "client",
"server"), which are frequent among various discussion topics. Additionally, we exclude exemplary schematic
terms that our experience shows do not add significant value to the discovered topics. This set includes
variable names such as "x," "foo," "bar," and "baz." Collectively, these exclusions help reduce noise, improve
stability, and increase topic coherence.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:10 • Amareen et al.

(6) Number/punctuation removal: since numbers and punctuation symbols are not tied to a particular topic, we
remove those.
(7) Stemming: this process reduces words to their origins by removing suffixes. For example, ‘mining’, ‘mine’
and ‘mined’ would all become ‘mine.’ We use the Snowball Stemmer [53] to convert derived words to their
base form.
(8) Bigram detection: a bigram is a pair of consecutive words frequent in a corpus. We identify the bigrams
that appear in at least 20 posts and merge those into a single token using an underscore (‘_’). For example,
‘public key’, becomes ’public_key’.
(9) Exclusion of very high or low-frequency words: we exclude high frequency (i.e., words appearing in more
than 20% documents, since those may not be tied to any particular topic. It also excludes low-frequency
words (i.e., words appearing in less than ten documents) since those are not significant terms for topic
analysis but can increase the model training time.

4.2.5 Determining Number of Topics. The optimal number of topics (𝐾) is essential to avoid undesirable outcomes.
For example, Mehdi et al. [28] documented that choosing a small K value may result in multiple, possibly unrelated,
topics combined into one. On the contrary, a large value of K may ultimately split what would otherwise be a
single coherent topic into multiple subtopics. Therefore, we run 45 LDA experiments varying the range of K
between 5 and 50 with a step increment of 1. For our LDA implementation, we leverage the Gensim LDA Python
library [7]. Our configuration brute forces the number of iterations for all experiments at 500 and 1000 iterations
following previous work [28, 60]. Additionally, Bigger et al. [32] showed that hyperparameters have little impact
on the accuracy of the produced topics; therefore, we set them at their default settings. To determine the best
number of topics, we employ three metrics: topic coherence, topic stability, and inter-topic distance map. We
measure topic coherence via the 𝑐_𝑣 score [54], extracting the top 15 words from each topic. For topic stability,
we utilize the Jaccard similarity score by repeating every experiment 10 times and comparing the top 10 words of
the produced topics. Lastly, we use the interactive topic model visualization tool (LDAvis) proposed by Sievert et
al. [57] to visually inspect the size, distance, and overlap of the discovered GraphQL topics. We take the best 𝑐_𝑣
score produced over ten runs for each value of K and also store a classification of all documents using the best
model. Figure 2 shows variations of CV scores with the number of topics. Our experiments show that (Figure 2),
at 500 iterations, K = 14 scores the highest 𝑐_𝑣 measure (0.57) with a stability score of (0.92). The inter-topic
distance map shown in Fig 3 shows little visual overlap across the generated topics. Therefore, we conclude that
K = 14 provides an optimal model for this study’s goal.

4.3 Topic evolution and trends

During our experiment to determine the optimum number of topics for our corpus (Section 4.2.5), we identified a
set of K topics (𝑧 1 ; ...; 𝑧𝐾 ) and a set of topic probability vectors for each post (𝑝𝑖 ) in our corpus. Following the
recommendations of prior studies [30, 41, 63], we compute the probability of a post (𝑝𝑖 ) belonging to the topic (𝑧𝑘 )
Í
as 𝜃 (𝑝𝑖 , 𝑧𝑘 ), where 𝐾1 𝜃 (𝑝𝑖 , 𝑧𝑘 ) = 1. With the topic probability vector for a post (𝑝𝑖 ), we computed its dominant
topic as

𝑑𝑜𝑚𝑖𝑛𝑎𝑛𝑡 (𝑝𝑖 ) = 𝑧𝑘 : 𝜃 (𝑝𝑖 , 𝑧𝑘 ) = 𝑚𝑎𝑥 {𝜃 (𝑝𝑖 , 𝑧 𝑗 )}, 1 ≤ 𝑗 ≤ 𝐾 (1)

Similar to prior studies [60, 63], we measure the popularity of a topic (𝑧𝑖 ) in our dataset using the ratio of posts
with 𝑧𝑖 as the dominant topic, as follows.

|{𝑑𝑖 }|
𝑝𝑜𝑝𝑢𝑙𝑎𝑟𝑖𝑡𝑦 (𝑧𝑘 , 𝑐 𝑗 ) = : 𝑑𝑜𝑚𝑖𝑛𝑎𝑛𝑡 (𝑑𝑖 ) = 𝑧𝑘 , 1 ≤ 𝑖 ≤ 𝑐 𝑗 (2)
|𝑐 𝑗 |

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:11

0.60

0.55
CV score

0.50

0.45
5 10 15 20 25 30 35 40 45 50
# of topics

Fig. 2. Best 𝑐_𝑣 score Vs. # number of topics (K). We repeated LDA model training ten times for each value K and took the
best CV score.

We use the following two metrics used in prior studies [41, 60, 63] to measure topic trends over time. The first
metric, called Topic absolute impact, measures the absolute proportion of posts related to a particular topic 𝑧𝑘 in
the month 𝑀𝑖 . It is defined as:
∑︁
𝑖𝑚𝑝𝑎𝑐𝑡𝑎𝑏𝑠𝑜𝑙𝑢𝑡𝑒 (𝑧𝑘 , 𝑀𝑖 ) = 𝜃 (𝑝𝑖 , 𝑧𝑘 ) (3)
𝑝𝑖 ∈𝐷 (𝑀𝑖 )

where 𝐷 (𝑀𝑖 ) is the set of posts in month 𝑀𝑖 . On the other hand, the Topic relative impact metrics normalize the
absolute impact by computing the ratio of posts in a month tied to a particular topic. It is computed as :
1 ∑︁
𝑖𝑚𝑝𝑎𝑐𝑡𝑟𝑒𝑙𝑎𝑡𝑖𝑣𝑒 (𝑧𝑘 , 𝑀𝑖 ) = 𝜃 (𝑝𝑖 , 𝑧𝑘 ) (4)
|𝐷 (𝑐, 𝑀𝑖 )|
𝑝𝑖 ∈𝐷 (𝑀𝑖 )

where |𝐷 (𝑐, 𝑀𝑖 )| is the set of all posts in the month 𝑀𝑖 .

4.4 Topic hierarchy

We assign each post to a topic cluster based on its dominant topic (𝑧𝑘 ). We ran a second-level LDA experiment
with each topic cluster’s posts to discover fine-grained subtopics for each topic separately. Our second-level topic
modeling follows a strategy similar to our top-level LDA experiments. However, as the number of documents
is smaller, we varied 𝐾2 from 2 to 5. This range choice (𝐾2 ) was motivated based on prior studies, where the
number of identified subtopics varied between 2 to 5 [28, 60]. We empirically identified the 𝐾2 value producing
each cluster’s highest 𝑐_𝑣 score. At the end of this second-level experiment, we identified two to five subtopics
for each first-level topic.

4.5 Topic-Naming Strategy

To name our discovered GraphQL topics, we adopt the following approach. Initially, we analyze the discovered
top terms of each topic utilizing the interactive topic visualization tool LDAvis [57]. We utilize the relevance
metric (i.e., Lambda) to identify the top-30 terms. At Lambda=0, a set of top-30 terms contains the most relevant
words but not necessarily the most frequent, whereas Lambda=1 favors the most frequent words over their

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:12 • Amareen et al.

Fig. 3. Intertopic distance map showing topic distribution, sizes, and overlap at the number of topics K = 14 (less overlap is
better)

corresponding relevance. We choose Lambda=0.6 because it is the recommended value according to the authors
of LDAvis [57] for visualization and selection of relevant terms.
Three authors independently reviewed each topic’s terms and subtopic terms produced through second-level
LDA to assign it a name and suggest their architectural mapping, which we will elaborate on in Section 4.6.
During this process, they also reviewed sample questions where the topic under review was dominant. After
this independent name assignment process, they met to compare and contrast their assigned names. While
the names assigned to topics differed due to differences in terminologies, in most cases, assigned names were
congruent. They discussed these name assignments, reviewed more questions as necessary, and determined an
agreed-upon name for each topic. Finally, they randomly sampled 20 SO posts from each topic to validate/refine
their naming. This process required multiple discussion sessions due to the sizeable number and amount of topics,
their associated subtopics, and architectural mapping.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:13

4.6 Topic to architectural layer mapping

In this step, we map each of the identified topics to the architecture layers of the GraphQL ecosystem developed by
us. As a starting point, we manually analyze the discovered GraphQL topics to determine their respective mapping
to the architecture layers. For example, a topic dominated by discussions about the Prisma [15] toolkit likely maps
to the server side of the architecture rather than the client side because Prisma is a tool that aims to migrate existing
databases to support a GraphQL API instantly. We found mapping ten of the 14 topics straightforward since they
cohesively contain posts constituting well-defined ecosystem concepts. On the other hand, the remaining four
topics, which include Pubsub Systems, GraphQL Java, Payload management and Microservice Architecture contain
posts that span a broad spectrum of cross-cutting concepts. Therefore, it is not easy to map such topics to one
layer.
To simplify our analysis, we consider a topic mapped to a particular layer if the posts related to a particular
layer form most of the posts assigned to a topic by our first-level LDA model. We randomly selected 30 posts
for manual analysis to identify the dominant layer for each of these four topics. Our analysis found three of the
four topics being mapped to the ‘API Integration’ layer. This mapping also justifies the cross-cutting nature of
questions belonging to these three topics. These three topics are also positioned in the center of our intertropical
distance map shown in Figure 3, indicating their cross-cutting characteristics. Section 5 elaborates on the concepts
in all topics and details their respective architecture layers.

4.7 Analysis of popularity and difficulty

Prior studies have used three metrics to compute the popularity of topics [24, 28, 60], which are i) the average
number of views, including both registered users and visitors of SO, ii) the average score, a metric to indicate the
number of times a post has been up or down voted, and iii) the average number of questions of a topic that are
marked by users as a favorite question.
We can not use the average favorite count since this metric is no longer present in the recent SO data
dump. Moreover, we use medians instead of averages for the remaining two measures since the results of our
Anderson–Darling tests [27] indicate that those significantly differ from a normal distribution. We measure the
difficulty of a topic using two metrics used by prior studies: i) the percentage of questions of a topic that have no
accepted answers and the median time needed for questions of a topic to receive accepted answers [24, 28, 60].
Intuitively, a topic with fewer accepted answers received or requiring a longer time is more difficult.

5 RESULTS
The following subsections present the results of our five research questions, respectively.

5.1 RQ1: How can we define a referenced architecture of the current GraphQL ecosystem?
Figure 4 represents our reference architecture of the GraphQL ecosystem resulting from the reference architecture
derivation process described in 4.1. The diagram depicts a client-server architecture where the GraphQL client
and server communicate over a network via an API integration layer. In a client-server architecture, a GraphQL
client requests resources from a GraphQL server using queries, mutations, or subscriptions. The server, in turn,
resolves requests, performs security checks and business validations, fetches resources from data sources, and
responds accordingly. The client receives the GraphQL response, stores it in local storage or cache if necessary,
performs respective business functionality, and renders the data on the user interface.
As shown, both GraphQL client and server operate at the application layer of the Open Systems Interconnection
(OSI) model. The GraphQL server has four components: business, data sources, GraphQL server, and framework.
The GraphQL client has five components: user interface, business, GraphQL client, framework, and local storage.
The diagram also shows that the tools and security components are cross-cutting because they apply to multiple

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:14 • Amareen et al.

Fig. 4. Our proposed reference architecture of the GraphQL ecosystem.

GraphQL client or server layers. The following subsections detail all layers and components of our reference
architecture for the GraphQL ecosystem.
5.1.1 Server side. According to our reference architecture, the four components of the server side of GraphQL
ecosystems are:
(1) Business Layer sits atop the layers of the GraphQL server. It is responsible for defining domain-specific
business rules and executing and validating business logic according to such rules.
(2) GraphQL Layer parses, validates, and resolves client GraphQL requests (i.e., queries, mutations, and
subscriptions). It contains schema-type definitions (i.e., typedefs) and resolver functions. The former defines
object types that correspond to the GraphQL schema. It allows the server to validate incoming GraphQL
requests. In contrast, the resolvers are functions that allow the server to handle the GraphQL operations
and fetch the resources from various data sources before responding to the client.
(3) Data Sources represents sources that GraphQL resolver functions connect to fetch, populate, and serve
data to the requesting clients. Data sources may be external, such as database systems and RESTful APIs,
or internal, such as in-memory data. Moreover, data sources are not only limited to the GraphQL layer
since the business or other layers may connect to them directly.
(4) Framework represents libraries and frameworks developers utilize to support GraphQL in their server-side
applications across various programming languages. Popular frameworks include Graphene-Django for
Python, GraphQL-Java for Java, and Express for Apollo-server. The full list of frameworks is available on
the GraphQL website [10].
5.1.2 Client side. The five components of the client side of GraphQL ecosystems are as follows.
(1) User Interface Layer sits at the top of the client-side layers. It applies to web-based front-end GraphQL
clients such as web and mobile applications. It incorporates graphical user interfaces (GUIs) and technical
web view components to visually present data to end-users and allow user interaction.
(2) Business layer has a responsibility similar to that of the server side, where clients perform various business
functionality for their respective front-end applications.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:15

(3) GraphQL layer allows a GraphQL client to create various GraphQL operations to interact with the
GraphQL server. A client creates, validates, and sends requests to the GraphQL server. Then, it receives
responses, caches results, and maintains the local state. GraphQL clients also utilize middleware to translate
requests and responses to the proper application protocol and manage authentication. GraphQL clients
vary in terms of features they provide, ranging from basic features to fully provisioned, such as Apollo,
which provides pagination and normalized caching.
(4) Local Storage refers to methods available in a web browser or mobile application that allow them to
store data locally on the user’s device. This data is persisted across browser sessions and is accessible
after a browser or mobile application is closed and reopened. Local storage is primarily used for saving
preferences, caching data to improve the performance of a GraphQL client, or allowing for offline use to
reduce constant dependence on the GraphQL server.
(5) Framework is similar to the framework component on the server side where software developers utilize
libraries and frameworks to support their front-end GraphQL applications. React is one of the most popular
frameworks used, and the full list is available on the GraphQL website [10].
5.1.3 API Integration. This layer has a few key responsibilities, as follows. Since the GraphQL specification is by
design transport-layer-agnostic [21], GraphQL client/server implementations utilize an API integration layer
responsible for managing lower-level requests/responses from underlying application programming interfaces
(APIs) and protocols. HTTP is the most widely used protocol for request-response models, whereas websockets [39]
is the most prevalent for publish-subscribe models. Additionally, this layer decouples the GraphQL layer from
the formats of integrated frameworks using middleware or integrations. The Apollo reference implementation
lists community-maintained integrations such as AWS Lambda, Fastify, Koa, and Hapi. The full list is available in
the Apollo integration documentation [3]. Moreover, one premise in GraphQL is the usage of a single GraphQL
endpoint (typically /graphql) to serve all requests. Mandating all services be exposed via a single API endpoint for
large-scale organizations is neither scalable nor efficient [58]. Organizations employ GraphQL API gateway or
federation to overcome such challenges, which fundamentally allows splitting the GraphQL schema into smaller
independent subgraphs that may be developed separately. The most popular GraphQL federation implementation
is Apollo Federation [13, 58]. In GraphQL federation, an API Gateway has a crucial role of receiving client requests
via a single GraphQL endpoint and routing them to the appropriate GraphQL subgraph, thereby stitching all
subgraphs and creating a supergraph of an organization’s overall GraphQL schema. Lastly, it provides a single
enforcement point to centralize specific security concerns such as authentication, API key management, and rate
limiting.
5.1.4 GraphQL Security. GraphQL APIs present unique security challenges because they are flexible compared to
REST APIs. While one strength is that clients can form complex queries to fetch exactly the data they require, this
also introduces specific security considerations to prevent malicious queries, protect sensitive data, and ensure
the data integrity and availability of the server. Therefore, the security component in the GraphQL ecosystem
is responsible for defining strategies, including input validation and sanitization, analyzing query complexity,
limiting query depth, rate limiting, authentication, and authorization.
5.1.5 GraphQL Tools. This component primarily encompasses the various GraphQL development tools, plugins,
and IDEs developers employ to manage their GraphQL applications throughout the software development lifecycle.
This includes tools to generate code, build, package, deploy, install, test, debug, and introspect GraphQL APIs. For
example, developers may use code generation tools to autogenerate GraphQL schema, code, or documentation.
Code generation tools that adopt schema-first approaches allow developers to design GraphQL schema, and the
tools generate the programming-language-specific code corresponding to their GraphQL type definitions. On the
other hand, code-first tools imply that developers write code before tools auto-generate the respective GraphQL

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:16 • Amareen et al.

schema. Examples of artifact life-cycle management tools include NPM, Apache Maven [14], and Gradle [8]. To
introspect, test, and debug GraphQL APIs, software developers may use various tools such as GraphiQL, Apollo
Studio, Insomnia, NPM, postman, curl, and GraphQL Playground. An elaborate list of tools can be found on the
GraphQL website [10].
Takeaway 1. GraphQL ecosystem has five primary architecture layers and is complex with various inter-
connected tools, technologies, and platforms from those categories.

5.2 RQ2: What do GraphQL developers discuss on StackOverflow?

Table 2. A list of our 14 discovered GraphQL topics, including our proposed topic names and their respective top-10 stemmed
words.

# Topic Name Top-10 Terms

1 Microservice API servic comment rest endpoint databas singl librari multipl backend support
2 Gatsby imag gatsbi content site plugin layout blog img tag style
3 Queries & Mutations compon load render react prop usequeri usest button state useeffect
4 Java Implementation public class date entiti private defin column scalar filter schema
5 Development Tooling npm build version gatsbi instal depend command modul npm_warn fail
6 GraphQL Server resolv schema await role apolloserv access ctx promis permiss datasourc
7 GraphQL Modeling model relat class def map refer float self graphen line
8 Payload Mgmt fragment upload relay cursor enum edg pagin kind viewer direc
9 Pubsub Systems subscript updat subscrib messag event appsync websocket connect lambda
pubsub
10 Security Mgmt email usernam token login password await userid profil regist account
11 Ecommerce Product Mgmt product categori slug order index filter test array mock key
12 GraphQL Client cach typenam header inmemorycach httplink apollocli cooki link token
appolloprovid
13 Prisma prisma databas connect migrat db postgr prismacli port docker environ
14 GraphQL Resolvers graphqlstr id graphqlobjecttyp resolv arg graphqllist graphqlnonnul mon-
goos schema express

After conducting our LDA experiments and following our topic naming and architecture mapping strategies,
we summarize the results of our 14 discovered GraphQL topics in Tables 2 and 3. The former table lists each topic’s
index (I) mapping to its intertopic distance map in Fig 3, our proposed topic name, and a list of its corresponding
top-10 words. Table 3 lists the names of all 14 topics as well as the names of their subtopics. Additionally, we
formally define all the topics we have discovered and provide evidentiary sample posts from the SO website to
support our naming.
(1) Microservice API: This topic contains developer discussions about the GraphQL microservice API. A
microservice architecture breaks business functions into small, independent, scalable, and loosely coupled
services with well-defined APIs instead of one monolithic application. In GraphQL, the microservice design
entails that services expose GraphQL APIs (as opposed to legacy APIs, e.g., REST) for clients to consume.
Our second-level LDA experiments suggest four subtopics as follows: API Consumption, API Fullfillment, API
Service, and API Autogeneration. The API Service subtopic is concerned with designing GraphQL services,
exposing GraphQL API endpoints, and utilizing API gateways. The prominent service API in this topic
is Amazon AppSync [1], part of the Amazon Amplify platform. The API Consumption subtopic involves

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:17

Table 3. A list of the names of our 14 first-level topics, the number of their associated second-level subtopics, and the subtopic
names

Topic Name # of Subtopics Subtopic Names

Microservice API 4 Service API, Client Libraries, Database, Schema & Resolvers
Gatsby 4 Image, Plugins, Script, Slug
Queries & Mutations 3 Data Fetching, Form Submission, Gatsby Prefetching
Java Implementation 4 Scalar Types, Dependency Mgmt, Java Constructs, ORM
Development Tooling 2 Build Tooling, Deploy Tooling
GraphQL Server 5 Server Management, Security, Modeling, Database, Resolvers
GraphQL Modeling 2 Graphene-Django, Prisma
Payload Mgmt 5 Pagination & Filtering, Mime-type Mgmt, JSON Content,
GraphQL Fragments, Enum Types
Pubsub Systems 4 Apollo Client, Websockets, Appsync, Event Modeling
Security Mgmt 3 User Authentication, User Payload, User Model
Ecomm Product Mgmt 2 Product Testing, Product Selection
GraphQL Client 4 User Interface, Apollo Links, State Mgmt, Cache Mgmt
Prisma 2 Schema Migration, Deployment (Docker)
GraphQL Resolvers 3 TypeDefs, Mongoose, NodeJS

libraries that GraphQL clients utilize to consume GraphQL APIs, such as "relay," "react," "redux," and
"Gatsby." The API Autogeneration subtopic concerns specific backend libraries that auto-generate GraphQL
schema from existing databases to instantly expose GraphQL APIs such as Prisma [15], Hasura [11] and
PostGraphile. Lastly, the API Fullfillment discusses resolver to fulfill client requests. Therefore, we have
mapped this topic to the API Integration layer of the GraphQL ecosystem. An example post from SO is the
following: "My company runs a microservice architecture that has 50+ services that are powered by a single
GraphQL endpoint, which orchestrate the calls among our services, powering our Android & iOS applications
for our end-users. We’re in process of creating a new product that’s going to not be used by those end-users, but
for companies that offer goods for our end-users through our apps. TL;DR: things like showing performance
data regarding their sales through our platform... In case your company had this discussion before, what was
the final decision made, what was taken into consideration?" [𝑄 54676109 ].
(2) Gatsby [6]: This topic represents developer discussions about Gatsby, an open-source frontend framework
that is based on the React framework and primarily targets static website generation. Gatsby also supports
other rendering options and is backed by a powerful GraphQL data layer that allows for dynamic data
fetching from multiple sources such as file systems, databases, REST, and GraphQL APIs (Data source).
Such data layer’s ability is enabled by various Gatsby plugins and automatic GraphQL schema inference
tools (Framework). This topic has four subtopics: HTML, Images, Slug, and React Integration, and image.
The HTML subtopic corresponds to the <script> tag in HTML, which Gatsby utilizes to help load JavaScript
scripts. The React Integration subtopic refers to the React-based Gatsby plugins developers utilize to build,
link, style, extend, and load their Gatsby projects. The Slugs subtopic contains Gatsby posts associated with
dynamic page creation. A slug uniquely identifies a resource on the web with a user-friendly URL. The
Image subtopic is concerned with automatically optimizing and displaying images for the web, such as
compressing and resizing them to reduce file sizes without sacrificing quality. Since all subtopics relate to
client-side integration, we map it to the Client layer. For example, a question on this topic asks, "I have
a Gatsby site set up with Sanity CMS for blogging. Current I am unable to properly target individual blog

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:18 • Amareen et al.

post (clicking on "First Blog" link will render content from "Second Blog"). My guess would be this is due to
how graphQL query is setup in template/[Link]? If so, what changes would need to be made to properly target
individual blog post?" [𝑄 72665818 ].
(3) Queries & Mutations: This topic contains developer discussions about triggering, executing, and rendering
GraphQL queries and mutations on the front end, especially using Apollo Client [12]. The discussions
involve managing user interface forms and triggering GraphQL queries and/or mutation eagerly or lazily
via the various hooks (e.g., useQuery, useMutation, and useLazyQuery), fetch and load data in the local state of
the GraphQL client, and render responses on the user interface. The React framework is the most dominant,
as the word "react" is present in 76% of the discussions. Our second-level LDA experiments produce three
subtopics. The first subtopic is Form submission, which includes top terms such as "button", "form", "submit",
"field" and "label". The second subtopic is Data fetching, which discusses various hooks to manage GraphQL
queries and/or mutations from the React framework. It contains top words such as "useEffect", "useQuery",
"useMutation" and "useLazyQuery". The last subtopic is about prefetching linked page’s resources in
Gatsby [6] to provide a faster user experience. Based on the discussion areas of the three subtopics, we
map it to the Client layer. The following is an example of a question posted on SO: "I was going through
the documentation of Apollo React hooks. And saw there are two queries hooks to use for which is useQuery
and useLazyQuery. I was reading this page. [Link] Can
someone explain me what is the difference between them and in which case it should be used." . [𝑄 63681650 ].
(4) Java Implementation: Posts on this topic concern implementing a GraphQL server in Java. Discus-
sions include developers requesting recommendations on the best GraphQL-Java implementation libraries,
modeling GraphQL using Java domain models, and defining GraphQL Java types. Developers also dis-
cuss underlying service containers such as Spring [17]. Our second-level LDA experiments produce four
subtopics: Scalar types, Dependency management, Java constructs and ORM mapping. The scalar types
subtopic is concerned with managing custom scalar types in Java, especially date/time types. This includes
the scalar type creation, serialization, format, and JSON representation. There are two types of dependency
management techniques present in dependency management, namely: bean and artifact dependencies. The
former discusses resolving the runtime injection of Java beans, especially in the Spring framework [17],
which GraphQL Java also uses as an application service container. The term "spring" is present in 13% of
the discussions. The artifact dependency involves resolving build time library dependencies using build
life-cycle management tools such as Maven [14] and Gradle [8]. The Java constructs subtopic contains
discussions around Java classes, interfaces, and functions utilized to resolver GraphQL queries. Lastly, the
ORM mapping subtopic discusses the object-relational mapping of Java entities to database tables. Based on
our analysis of the posts and subtopics, we map this topic to the Server layer of the reference architecture.
One example post is the following: "I need a graphQL client for java spring application to communicate with
another microservice based on graphQL API. I know about Apollo Android but it seems to be not implemented
with maven...Any ideas and suggestions?" [𝑄 68019255 ].
(5) Development Tooling: As the top 10 words of this topic suggest, it contains questions and answers
concerning tools developers utilize through the development of GraphQL projects. These tools play a
crucial role in the GraphQL ecosystem by facilitating the installation and management of libraries, tools,
and dependencies necessary for both server-side and client-side GraphQL development. We map this
topic to the Development Tools layer of our reference architecture. A few examples of tools present in
developer discussions of this topic include Yarn, npm, and Webpack . Node Package Manager (NPM) tops
the top 10 terms of the parent topic and is present in 36% of the discussions. Therefore, we consider it
the most widely used artifact package manager in the context of GraphQL. Our second-level GraphQL
experiments produce two subtopics, namely: Build tooling and Deploy tooling. As the names suggest, Build
tooling contains discussions that concern resolving dependencies or building GraphQL packages, whereas

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:19

Deploy tooling concerns deploying GraphQL artifacts to cloud platforms such as Netlify and Heroku. The
following example SO answer suggests a developer use a command-line tool that utilizes NPM to generate
a GraphQL project with support for typescript: "I am using a GraphQL CLI. You would install it like so
npm install -g graphql-cli then generate your GraphQL project with TypeScript support" [𝑄 50905873 ].
(6) GraphQL Server: In this topic, software developers have various discussions about managing GraphQL
servers and naturally map to the Server layer of our reference architecture. The spectrum of discussion
points includes creating, configuring, and securing the server in addition to managing server middleware,
business modeling, and data access. The most prominent server implementation developers discuss is
Apollo Server which occurs in 34% of the discussions. Our second-level LDA experiments produce five
subtopics as follows: Server management, Security, Modeling, Database and Resolvers. The first subtopic
concerns managing the GraphQL server (e.g., Apollo Server), HTTP middleware such as the Express server,
API endpoints, and the federation gateway. The Security subtopic contains discussions about Auth Guards,
which is a mechanism to protect certain parts of the GraphQL API by ensuring that the user making a
request is authenticated and authorized to perform the requested operation. It also involves the management
of users, security groups, and permissions. In the Modeling subtopic, discussions are regarding managing
business data models for GraphQL resources. Posts in the Database subtopic involve managing database
tables and various selection, filtering, and join queries to resolve GraphQL requests. Lastly, the Resolvers
subtopic concerns how requests are resolved and how data is retrieved, processed, and returned in a
GraphQL API. In this subtopic, there is a special emphasis on passing input arguments and resolving nested
queries. An example post from SO is: "I want to implement cursor based pagination in Apollo graphql server.
I have prepared schema with pagination requirement. But i am stuck at resolver side. Here is my schema... Is it
possible to resolve in resolvers? If yes, can any one please tell me how to implement it" [𝑄 44383522 ].
(7) GraphQL Modeling: This topic contains questions and answers about GraphQL schema definition and
its respective object relationship modeling. It aims to generate GraphQL schema definitions and realize
their equivalent object model or entity model in a programming language or database schema, respectively.
Since data models are implemented on the server side, we map this topic to the Server layer of our reference
architecture. Our second-level LDA experiments suggest two subtopics that correspond to two backend
framework models. The first framework is Prisma, which we detail separately in the Prisma topic description.
The second is Graphene-Django [9], a Python framework to enable the development of GraphQL backend
APIs. As the name suggests, Graphene-Django represents an integration of two Python frameworks, namely
Graphene and Django. The former is an open-source Python library that allows for building GraphQL APIs
using a code-first approach, contrasting with schema-first approaches. For example, in the Ariadne [16]
python library, developers start with writing the GraphQL schema before the respective code is generated
thereafter. On the other hand, Django [5] is an open-source Python web framework for building server-side
projects and web pages. Graphene-Django supports query validation, subscriptions, middleware, and data
modeling backed by data loaders to facilitate integration with various data sources. The following is an
example question from SO: "I am using Django 4 with graphene-Django 3 and I need to structure a response
that must be 4 levels of lists and the bottom level a dictionary...GraphGL takes more than 30s to parse the given
result...I am not an expert in GraphGL...how could I speed up graphene-Django to parse this response faster..."
[𝑄 74154000 ].
(8) Payload Management: Questions and answers in this topic are regarding either constructing valid
GraphQL requests (e.g., fragments) or consuming response messages appropriately. Our second-level
LDA experiments suggest five subtopics, namely: Pagination and Filtering, Mime-type management, JSON,
Fragments, and Enum types. The first subtopic involves managing search operations to perform pagination,
cursor navigation, selection, filtering, sorting, and ordering using the Relay framework. This framework

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:20 • Amareen et al.

provides complete specifications for GraphQL cursor connections and pagination. The Mime-type man-
agement subtopic contains posts concerning the management of multipurpose internet mail extensions,
such as uploading files and images. The term "file" appears in 22% of the parent topic’s posts. In the JSON
subtopic, developers inquire about clients receiving, parsing, validating, converting, and formatting JSON
payloads. We note that the term "json" is present in 19% of the posts. We also note that developers ask
questions regarding handling erroneous messages or correcting ill-formed GraphQL requests and validating
them against the GraphQL schema. In the last two subtopics, developer discussions are about managing
client-side Fragments and passing Enum types as part of the GraphQL requests. For instance, the term
"error" appears in 32% of the posts. Based on our analysis of the subtopics, we map this topic to the API
Integration layer. The following question is an example: "Our app uses Algolia for searching which allows for
two typical forms of pagination: by page page=3&hitsPerPage=5 or by offset offset=10&length=5 GraphQL
preferences cursor-based pagination where a recordID and length are provided friendsConnection(first:5 af-
ter:"Y3Vyc29yMQ==") Is there anyway to translate info from a cursor-based pagination request into a page or
offset pagination request?" [𝑄 50033816 ].
(9) Pubsub Systems: The top ten terms in this topic such as subscript, subscribe, and pubsub suggest that
posts are related to the GraphQL publish-subscribe paradigm (i.e., pubsub). GraphQL subscription is the
third operation type that GraphQL supports, in addition to queries and mutations. Therefore, we map
it to the (GraphQL) layer. In contrast with request-response models, GraphQL subscriptions follow a
publish-subscribe mechanism where clients subscribe to the server and establish long-lived connections.
On the other hand, the server is responsible for managing connections, routing, and publishing event
messages to its subscribed clients. Our second-level LDA experiments produce four subtopics: Apollo client,
WebSockets, Amazon Appsync, and event modeling. We find that the main protocol implementation of
GraphQL subscriptions is WebSockets [39], which ranks 7th in the top-10 terms and appears in 15% of the
posts. Since WebSockets is a transport protocol, we map it to the (API Integration) component of our derived
reference architecture. Amazon Appsync also appears in the top-10 terms and accounts for 34% of the
discussions. This finding suggests Appsync is the dominant backend for GraphQL subscriptions, whereas
Apollo is the main client. Moreover, we observe that developers discuss libraries that support subscriptions
(Framework). An example question from this topic asks "I am using Appsync subscription for pub/sub messages.
I have read some articles about subscriptions (like [Link]
[Link]), and all of them mentioned specifying a GraphQL schema directive on a mutation. In my
case, I have a lambda which is triggered by dynamodb streams and that lambda needs to publish the event to
subscribers. How can I make this work in Appsync? I can’t find any API I can use to publish event to Appsync"
[𝑄 62145701 ].
(10) Security Management: This topic contains developer discussions about the security management of
GraphQL on both the client and the server sides. This includes passing user ID and password, acquiring
and managing JSON web tokens, passing authentication headers to the server, and validating user sessions
on the server. The term "token" appears in 41% of the posts. Our second-level LDA subtopics are User
authentication, User payload, and User model. The User authentication subtopic discusses acquiring valid
authentication tokens on the GraphQL client and passing them to the GraphQL server. The top terms in this
subtopic include "authent", "compon", "link", and "header". The dominant framework to authenticate clients
is React, as it is present in 29% of the parent topic’s posts. Additionally, it is incumbent to note that the
GraphQL specification, which is protocol-agnostic by design, does not address authentication and rather
leaves it as an implementation detail. Hence, GraphQL libraries such as Apollo-Link support authentication
as a middleware adapted at the integration layer of the architecture. The User payload subtopic contains
user data passed between the GraphQL client and server. A few of the top 10 words of this subtopic include

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:21

"firstname", "lastname", "regist", "phone" and "pass". Lastly, the User model subtopic defines the server-side
model used to resolve operations and fulfill authentication on user accounts. The top terms include "userid",
"model", "account" and "session". Based on our analysis above, we map this topic to the Security layer of our
reference architecture. The following is an example post: Another example is: "I have a login which takes as
inputs an email and password and when I press the button I have defined that the function handleLogin is
called. The code of this function is as follows...If I type an incorrect username or password and press the button,
I receive the corresponding "incorrect username or password" alert..." [𝑄 74117267 ].
(11) E-commerce Product Management: Posts on this topic concern the consumption of e-commerce manage-
ment GraphQL APIs. Our second-level LDA experiments suggest two subtopics corresponding to Product
Testing and Product Selection. The Product Testing subtopic discusses testing GraphQL services offered by
popular e-commerce services such as Shopify to ensure that new listing and their updates are reflected
accurately. The Product Selection subtopic discusses searching for e-commerce resources such as stores,
products, tags, and variants using GraphQL queries. Based on our analysis, we map this topic to the Client
layer. An example post is the following: "I am working on fetching Shopify products based on the product tag.
I did the below code for it, and it’s working fine when I put the AND condition, But it does not work with the
OR condition. It shows products where a tag appears in text content." [𝑄 73063005 ].
(12) GraphQL Client: This topic contains developers’ discussions regarding the use of the GraphQL client and
various client libraries. The dominant GraphQL client is the Apollo client [12], which we find present in
47% of the posts. Apollo client represents the reference GraphQL client, which is implemented using the
JavaScript React framework. This client features a set of components and techniques to allow local state
management, data management, normalized in-memory caching, pagination, and more. It also provides
various view integrations to frameworks such as Vue, Angular, and Ember. Our second-level LDA experi-
ments produce four subtopics, namely: State management, Cache management, User interface, and Apollo
link libraries. State management includes questions on local state management in GraphQL clients. Cache
management ranges from simple operations, such as adding, updating, and removing data from the cache,
to complex ones, such as defining cache policies, invalidation, optimistic responses, and normalization
operations. User interface discusses data view management on the client side. Apollo link libraries are
fundamental to the architecture of the Apollo client. They help compose chains of functions to modify
requests and responses as they pass through the client, such as HTTPLink, AuthLink, WSLink, and Batch-
Link. Based on our analyses of these four subtopics, we map this topic to the Client layer. One SO example
post is: "...I would like the list to update and remove the deleted organization but that is not working...I have
set up a cache exchange like this...I have (redundantly) tried two cache invalidation methods...The GraphQL
query that returns... And the mutation to delete an organization looks like...[Link] does not appear to
do anything. I have checked the cache using the debugging plugin...I can see the records in the cache and they
don’t get removed." [𝑄 72385225 ].
(13) Prisma [15]: This topic consists of posts regarding Prisma, an open-source server-side toolkit that instantly
creates GraphQL APIs for existing databases using object-relational mapping (ORM). Prisma is implemented
using NodeJS and Typescript. Since Prisma operates on the server side, we map it to the Server layer of
the GraphQL architecture. Depending on the target database Prisma connects to, the toolkit automatically
creates a specific Prisma schema using a Prisma modeling language. It also autogenerates a Prisma client to
allow data to be retrieved from various database systems. Some databases it supports are MySQL, MongoDB,
SQL Server, and PostgreSQL. GraphQL resolvers can use the Prisma client to expose the retrieved data as a
GraphQL API. Prisma has two integration plugins to two GraphQL libraries (i.e., Nexus and TypeGraphQL)
both of which help autogenerate GraphQL types and resolvers. Our second-level LDA experiments produce
two subtopics: Schema migration and Deployment. The first subtopic contains posts that concern database
migration in Prisma using the command-line interface, i.e., Prisma CLI. The deployment subtopic discusses

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:22 • Amareen et al.

deploying Docker images of Prisma servers to cloud platforms such as Heroku and Hasura [11]. The
following is an example Prisma post on SO: "what is the difference between prisma db push and prisma
migrate dev ? When should I use one over the other. Docs say that prisma db push is about schema prototyping
only and I don’t understand what does that mean." [𝑄 68539836 ].
(14) GraphQL Resolvers: This topic contains questions and answers regarding fundamental server-side
GraphQL resolver functions and schema type definitions, such as defining input and output types, fields,
arguments, lists, queries, mutations, and resolver functions, in addition to managing and exporting schema
files. Additionally, the topic involves discussions about user-defined types that GraphQL does not support
natively (e.g., date types). We observe that developer discussions mostly concern server-side JavaScript
applications predominantly utilizing the NodeJS framework and a few associated frameworks. This includes
TypeScript, NestJS, Express, and Apollo Server. Moreover, developers discuss how to build GraphQL
resolvers to fetch and manipulate data fetched from the database, and the most prevalent example is
MongoDB using the Mongoose schema. The term "mongo" appears in 26% of developer discussions within
this topic. Therefore, we map it to the Server layer. Our second-level LDA experiments confirm the above
findings, presenting three subtopics, namely: TypeDefs, NodeJS, and Mongoose. One example from SO is: "I
am creating a gql express server and i have created multiple schemas and referenced those schemas into each
other. Assume collection USERS. Each user will have multiple challenges(schema or collection - challenge). I
want to store the document(challenge) id into an array of challenges inside the user document that created it
and vice-cersa. How can I acheive this? My user Schema...My challenge Schema...I have to also perform gql
query to get the challenges details of the the user and also have to query all the users of a particular challenge"
[𝑄 69316367 ].
Takeaway 2. Due to the complexity of the GraphQL ecosystem, developers discuss a diverse range of topics,
including setup, migration, domain modeling, security, tooling, and API integration.

5.3 RQ3: How can we organize GraphQL discussions on StackOverflow into a hierarchy of topics?
Figure 5 is a sunburst chart that shows our GraphQL topic hierarchy consisting of three rings as follows. The
innermost ring, which contains five architecture layers, corresponds to the GraphQL ecosystem and components
we presented in Section 5.1. The second ring consists of 14 segments corresponding to our discovered GraphQL
topics listed in Table 2. The outermost ring contains 47 subtopics listed in Table 3 where each set of subtopics
belongs to a specific topic. Each topic segment has a parent architecture category and its own set of subtopics.
For example, the topic GraphQL Java belongs to the GraphQL server category and has four subtopics, namely:
scalar data types, constructs, dependency management and object-relational mapping. Furthermore, at any given
level in the hierarchy, each segment is associated with a percentage representing its absolute size measured by its
share of questions divided by the total number of questions.
Takeaway 3. Software developers’ discussions about GraphQL are grouped into a topic hierarchy of 5
architecture categories, 14 topics, and 47 subtopics. The 5 top-level categories are: GraphQL Client, GraphQL
Server, API Integration, Security Management and Development Tools.
As shown, two-thirds of all GraphQL discussions concern either GraphQL server or client architecture layers,
and each category segment amounts to almost one-third of the GraphQL discussions. On the other hand,
GraphQL security and tooling are the least discussed GraphQL categories since either corresponds to about 5% of
all discussions. Finally, about 25% of the discussions concern API integration between client and server.
Takeaway 4. About two-thirds of software developers’ GraphQL discussions are equally contributed by
GraphQL client and server categories.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:23

Product Testing

ries
Authen
Cach 1.23%

ries
Apo

ion Que
Manag
Sta

e Ma

2.46 n Que
ticatio

2.66%
llo
1.2 nagem

1.86%

s
te

rie
Ja

2.77%
Clie
2%

nage
Ma %

ement
va

ue
t Select
1.1

n Cook

sio
%

2% g Q
nt
2
Sc 2.03
Ja

men

bmis

3.4 chin
ala
va .9 denc t

ie
ent

6% es g
t

Produc
rD
Ja M 1.

a Su

fet

4. ri hin
C 7 y
va an 74

1
on %

re
ata
D age %

yP
Ja

ep m

ue c
Dat
st
va

Q Fet
en e

t
Ty

tsb
ru
O

Ecommerce Produc
bj
Qu

Grap
pe
e
ML

ct

Ga
M ct
er

Management
a -

a
In 1. pp Rel HT on

s
pu y&

at
by ti
6 in a
t A 8% g tiona ts gra

D
5.43%
Ha rgu 10 Mu a
G nte 9%

hQL
l

5.43
n .4 I 1.
es
2. dlin men
8% tatio

Gr 7
Pe 28 g t ag

ap .42
rm
iss
% n Im
y

Clie
%
i
tsb .2%

hQ %
1.6 on M
Ser 6% gm Ga 2
ugs

L
ver t

nt
M
1.3 odelin Sl

Ja
sby
6% g
Apo Gr

va
Gat .88%
llo S
e
1.24 rver
ap
hQ
Auth
entic
%
ation
L
7.4 Serv
2
Cont
1% er Gatsby
eact
ext M
Client
0.87 gmt
%

11.16% Gatsby R
32.5% on
Prisma Modelin
g Integrati
4.17% Server 4 .1 8 %
GraphQL Modeling
6.84%
32.04% Securi
ty Secu Authentication
De 5.27% rity Ma 1.52%
ve nagem
eling lop
5.27% ent
ne Mod m Securit
y Sess
Graphe 5.8 ent
Managem ion
Python % Too
2.67% ls D ent
ev Acco 1.76%
elo unt
Prisma ion
API Integrat
Reg
tion pm istra
era rs e
5.8 nt T 1.99 tion
Gen 5.86% ve De %
ma ol 25.5% % ool plo
Pu
Pris 3.06% s ing y
Re
nt 2.6 Toolin
me bs 6.3
L 1%
Pay

ub 1%
ploy phQ .5 Bu 8% g
e 4 ild
load 45%

ra
aD % Sy
3. Too
sm 2.8 G
Pri Micr st
6.

s
em 12 lin
Man

n
on
ct
io
iti ose % g
un s
rv
Am
in s
12.7 ice API
r f on ef
Su
age

az
ve niti D b

on
l sc
so fi 9%
pe %
r
s

(W ipt

Ap
Re de 1.6 4%
n
ce

men

ty 2 e ion

pS 1
% ptio
ur

5 1. bso Pr
1.
yn .5
a
% so

c 5%
46 ck ot
em
Su
Ev
.3 ta

% et oc
t

ch
)

bs
ol
1 a

3. um

3.3 llmen
D

en 1.5

cr
S
Ev 1.7 load M

ip
er

Mim

tio
t M 9%
API Autogeneration
lv

Pagin

n
en
Fra
so

M
54
on

e-t

gm
od
rvice
Re

Json Pa

gm

t
9%

t
yp .11%
E

el
IC

Ca
num
ated

eP
fi

ent .13%

in
1
2.97%

1% gmt
Ful

ch
2.84%

ay

g
AP

1
Pay
Pay %
1.4%
Paylo

ing
1.62%

1.1
API Se

yload M

lo
load

ad
9
API

ad M

Mg
Mgm

mt
gmt
gmt

Fig. 5. Hierarchy of GraphQL topics, their architecture layers, subtopics, and percentage of their questions.

Even though the API Integration layer ranks third in terms of its size among all architecture categories, we
note that the Microservice API topic represents the largest GraphQL topic, containing 12.74% of the discussions.
On the other hand, GraphQL Resolvers is the least discussed topic at 4.5% despite belonging to the most discussed
GraphQL category, i.e., GraphQL Server.
Takeaway 5. Microservice API is the most discussed GraphQL topic, whereas the topic GraphQL Resolvers is
discussed the least.

5.4 RQ4: How did GraphQL discussion topics on StackOverflow evolve?

To investigate the popularity of GraphQL, we analyzed the absolute and relative impact trends of GraphQL
architecture categories. First, we calculated the absolute impact (3) of the GraphQL categories quarterly from
August 2015 to November 2022, as shown in Figure 6. We exclude December 2022 since that month’s data is
incomplete. We observed an increase in the absolute impact for the categories GraphQL Client, GraphQL Server

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:24 • Amareen et al.

API Integration Client Development Tools Security Server

400

300
Absolute impact

200

100

0
08

12

04

08

04

08

12

04

08

12

04

08

12

04

08

12

04

08

04

08
1

1
2015

2015

2016

2016

2016

2017

2017

2017

2018

2018

2018

2019

2019

2019

2020

2020

2020

2021

2021

2021

2022

2022
Fig. 6. The absolute impact scores of GraphQL topics at various architectural layers in our dataset between August 2015 and
November 2022.

and API Integration. This increase is justifiable as the three categories correspond to new technologies proposed
in the GraphQL specification. The increase in discussions may be attributed to several factors highlighting the
growing interest, continued evolution, and adoption of GraphQL, especially as it peaked in December 2019
and August 2020. Some of these factors may include the announcement of the GraphQL Foundation and the
establishment of the GraphQL specification project in 2019, the adoption of GraphQL by major companies,
GraphQL conferences, and online events. The top contributor to the absolute impact during that period is the
GraphQL Client. Interestingly, the top contributor to the absolute impact changes starting around October 2021
to become the GraphQL Server. This coincides with the release of the October 2021 GraphQL specification, which
still represents the latest release when writing this paper.
On the other hand, the absolute impact continued to stay stagnant for GraphQL Security and Development
Tools. One explanation is that these categories represent areas of less GraphQL innovation. Concerning GraphQL
Security, the GraphQL specification claims a transport-agnostic approach that does not directly address security
and leaves the details up to implementation protocols such as HTTP or WebSocket. Additionally, software
developers’ discussions under Development Tools represent utilizing already existing tools (e.g., WebPack, NPM,
and Yarn) to build and deploy GraphQL applications.
Takeaway 6. According to absolute impacts, GraphQL client and server are the top two architectural layers
attracting discussions on SO. Discussions of the GraphQL server are showing an increasing trend.
We calculated the relative impact (4) of five GraphQL architectural layers quarterly from August 2015 to August
2022, as shown in Figure 7. Before December 2017, we observed a high relative impact of API Integration that
continues to decrease as the relative impact of both GraphQL Client and GraphQL Server increases. The initial
intense change in the relative impact is likely associated with the public release of the GraphQL specification in
2015. In contrast, the continued changes in the relative impact until December 2017 are likely associated with the

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:25

API Integration Client Development Tools Security Server

60%
Relative impact

40%

20%

0%
08

12

04

08

12

04

08

12

04

08

12

04

08

12

04

08

12

12

04

08
0

0
2015

2015

2016

2016

2016

2017

2017

2017

2018

2018

2018

2019

2019

2019

2020

2020

2020

2021

2021

2021

2022

2022
Fig. 7. The relative impact scores of GraphQL topics at various architectural layers in our dataset between August 2015 and
November 2022.

frequent releases and evolution of the GraphQL specification. The latter is an observation consistent at all points
where the relative impact changes. We also observe a flat trend for both GraphQL Security and Development
Tooling. This reinforces our initial explanation that these categories are areas of less GraphQL innovation and are,
therefore, less impacted by GraphQL releases.
Takeaway 7. Discussions GraphQL API integration was majority till December 2017 for early adopters, who
were integrating services offered by large organizations. In recent years, client and server-related discussions
have seen increased shares, suggesting more organizations are implementing their services using GraphQL.

5.5 RQ5: What are the difficulty and popularity of various GraphQL topics?
Table 4 ranks the GrapQL topics based on difficulty measured using % of questions without accepted answers.
We consider this metric a more accurate representation of topic difficulty since answer delay can be influenced
by when a question is being asked (e.g., holiday, weekend, off-hours). Our results indicate that questions indicate
that more than two-thirds of questions on Pubsub Systems, GraphQL Client, and Prisma have no accepted answers.
These three topics represent three different Architecture layers. Moreover, Security, the fourth most difficult
one, represents another layer. We also noticed that a ranking based on delay would also have Pubsub Systems
and GraphQL client at the top two spots. On the other hand, GraphQL Resolvers, Gatsby, and Query & Mutation
represent topics with the least difficulty both in terms of the ratio of questions with accepted answers and median
answer delay.
Takeaway 8. Pubsub Systems, GraphQL Client, and Prisma are three most difficult topics, while GraphQL
Resolvers, Gatsby, and Query & Mutation are three least difficult ones.
Table 5 ranks GraphQL topics based on median views. GraphQL Client, Development Tooling, and Query &
Mutation are the top three most popular topics. On the other hand, Prisma, Microservice API, and E-commerce

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:26 • Amareen et al.

% W/O accepted Delay hrs

Topic Layer
answer (median)
Pubsub Systems 0.69 18.14 API Integration
GraphQL Client 0.68 13.22 Client
Prisma 0.68 10.16 Server
Security Management 0.65 4.01 Security
Microservice API 0.65 9.93 API Integration
Development Tooling 0.64 10.49 Tooling
E-commerce management 0.63 5.66 Client
Java Implementation 0.63 8.48 Server
GraphQL Modeling 0.63 10.32 Server
Payload Management 0.62 6.33 API Integration
GraphQL Server 0.61 7.79 Server
Query & Mutation 0.59 2.98 Client
Gatsby 0.57 5.10 Client
GraphQL Resolvers 0.56 3.56 Server
GraphQL (all) 0.63 6.88
Table 4. Ranking of GraphQL discussion topics based on difficulty.

Topic View (median) Score (median) Layer

GraphQL Client 458 1 Client
Development Tooling 440 1 Tooling
Query & Mutation 437 1 Client
GraphQL Resolvers 433 0 Server
Payload Management 423 1 API Integration
Java Implementation 416 1 Server
Pubsub Systems 407 1 API Integration
GraphQL Modeling 397 1 Server
Gatsby 376 1 Client
Security Management 361 0 Security
GraphQL Server 360 1 Server
E-commerce Management 341 0 Client
Microservice API 328 1 API Integration
Prisma 323 0 Server
GraphQL (all) 387 1
Table 5. Ranking of GraphQL topics based on popularity

management are the three least popular topics. Our results do not indicate any association between popularity
and Architecture layers, as the top five topics represent four layers. The median scores for all the topics are either
0 or 1, indicating no difference between the topics in terms of this measure. We want to mention that we do not
use mean Scores, which have been used in many prior studies. We found that the Scores of the questions on SO
are highly skewed, and few outliers can distort the means.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:27

Takeaway 9. GraphQL Client and Development Tooling rank top in terms of median views, while Prisma and
Microservice API rank bottom.

6 DISCUSSION
The following subsections detail key implications based on the results of this study.

t
lien
L C
Popular & Easy phQ
Gra

ng
ooli
440 ation
me nt T Popular & Difficult
olve
rs Mut elop
Res ry & Dev
L Que
phQ t
Gra men
age
d Man n
lo a tatio
Pay
p le men
a Im ms
Jav yste
subS
Pub
Median views

g
400 elin
Mod
ph QL
Gra

sby
Gat

ent
ver gem
360 L Ser M ana
phQ urity
Gra Sec
t
men
age
Man Unpopular & Difficult
erce
mm
Eco API
Unpopular & Easy rvic
e
rose ma
Mic
320 Pris

0.55 0.60 0.65 0.70

% questions w/o accepted answers

Fig. 8. Significance of GraphQL topics using topic size and tradeoffs between topic popularity and difficulty.

6.1 Most Impacting Issues

Figue 8 analyzes the tradeoff between the popularity and difficulty of the identified topics. The bubbles for each
topic represent the topic size, defined as the percentage of SO questions contained within it. For example, the
topic Microservice API is the largest topic as it contains 12.7% of the questions. In contrast, the topic GraphQL
resolvers is the smallest in size with a percentage of 4.5%. The y-axis represents topic popularity measured by the
median view count. The x-axis represents topic difficulty measured by the percentage of questions without an
accepted answer. The plot also presents two median lines for all GraphQL questions (colored in red), dividing the
plot into four quadrants, forming an effort-to-impact matrix [45]. We describe the quadrants as follows.
• The Popular and Easy quadrant includes topics requiring less difficulty since they are more likely to have
accepted answers. Yet, those are important for the GraphQL community due to the high number of views
they receive. Four topics belong to this quadrant, which are GraphQL Resolvers, Query & Mutation, Payload
Management, and GraphQL modeling. Therefore, GraphQL experts who want to improve their reputation
score of SO can focus on these topics to maximize their return on investment (ROI).
• The Popular and Difficult quadrant represents difficult topics due to the lower probability of having
accepted answers. However, these topics are significant due to high community interests. Hence, GraphQL

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:28 • Amareen et al.

framework builders should prioritize improving support and documentation on these four topics, which
include GraphQL Client, Pubsub Systems, Development Tooling, and Java Implementation. Although these
topics represent four different architecture layers, they relate to implementing new applications using
GraphQL.
• The Unpopular and Easy quadrant contains GraphQL topics that are more likely to be answered and
have a lower community impact than the topics from the popular half. Two topics belong to this quadrant,
which are Gatsby and GraphQL server. According to our results, these topics do not require immediate
attention.
• Finally, the Unpopular and Difficult quadrant contains difficult topics with less community impact. Four
topics belong to this quadrant: Security management, Prisma, E-commerce management, and Microservice
API. Although these topics currently have a lower community impact, the number of questions on these
areas is significant. Noticeably, Microservice API, which has the highest ratios of questions, belongs here.
Hence, although many users are not encountering challenges in these areas, many unresolved issues remain.
Since GraphQL adoption is a rapidly growing technology, these challenges will be encountered by more
community members. Hence, topics from this quadrant should receive the second most priority from
GraphQL framework builders.

6.2 Implications for Practitioners

Our analysis of popularity (Table 5) and difficulty (Table 4) suggest that tools from the GraphQL ecosystem lack
adequate support as approximately two-thirds of questions on Prisma and Development Tooling do not have
accepted answers. Our analysis suggests that many questions on these topics inquire how to achieve particular
objectives using these tools. For example, “How to use mongodb’s increments operator ($inc) in prisma ORM? I cannot
find a way to use some special MongoDB operation on prisma: In MongoDB I can do this:"[𝑄 73556355 ]. Automated
tools play an important part in promoting the adoption and ease of onboarding of new practitioners. Hence,
GraphQL tool builders should focus on creating FAQs and examples detailing such common usage patterns.
As discussed in Section 2, a GraphQL server supports three operations, i.e., Query, Mutations, and Subscription.
Our results indicate that while questions on Queries & Mutations fall under the lower end of difficulty spectra,
PubSub Systems is one of the most difficult topics. Despite having thousands of views, indicating popularity, the
majority of questions on subscription do not have accepted answers. Our analysis suggests that many questions are
about setting up and testing basic subscriptions. For example, “I have a secure subscription endpoint on my Apollo
server. I can send subscription connectionParams from my react client by setting it in the WebSocketLink constructor
and verify it in the onConnect property of Apollo Server constructor. But how do I test these subscriptions on GraphQL
Playground?"[𝑄 63635513 ]. Hence, we recommend GraphQL foundation to focus on improving documentation,
support, and tutorials on subscription operations.
For managers considering an adoption, GraphQL specification is language agnostic, and GraphQL has imple-
mentations in popular programming languages such as [Link], Java, Python, Go, .Net, and Rust. However, our
results suggest that not all implementations have the same level of support and popularity. Since the reference
implementation uses JavaScript (i.e., [Link]), this ecosystem has matured tools and better community support.
While an enterprise-based application may prefer Java due to performance and existing developers’ familiarity
with the Java ecosystem, our results indicate that Java implementation currently has less support than JavaScript-
based ones. Moreover, GrahpQL client-related areas such as GraphQL Resolvers and Query and Mutation are less
difficult, yet popular. Based on this result, we recommend newcomers onboarding to the GraphQL ecosystem
begin with these areas to understand basic building blocks and usage of GraphQL before moving to a more
challenging topic such as GraphQL server and GraphQL Modeling.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:29

6.3 Implications for Researchers

The design of GraphQL imposes unique security challenges [48, 64, 66]. For example, GraphQL allows for query
batching, where multiple queries are sent in a single request, and aggregation, where multiple pieces of data
are fetched together. These features can be exploited to perform more efficient attacks, such as extracting large
volumes of data in a single request, leading to Denial of Service attacks. Moreover, implementing fine-grained
access control in GraphQL can be challenging because of its flexible nature. Ensuring that users can only access
the data they are authorized to see requires careful design and enforcement of authorization rules at the field level.
Our results indicate that i) only 5% questions are on security, ii) Security is not a popular topic in terms of views,
and iii) security remains the fourth most difficult topic in terms of questions without accepted answers. These
results may indicate that developers often do not have adequate knowledge or even no solutions to implement
security in GraphQL server implementations. In some cases, although developers want to implement security,
existing frameworks lack support. For example, “I have a very straight forward graphQL app built on top of AWS
AppSync, and I want to configure support for HTTP Strict Transport Security (HSTS) so that’s my question how
can I enforce a support HTTP Strict Transport Security (HSTS) on AWS AppSync or how can I add an HTTP header
in the AppSync response" [𝑄 63347634 ]. Since is expected to see rapid adoption across various industries [37], we
recommend researchers to explore solutions to integrate security at various GraphQL layers.

7 THREATS TO VALIDITY
Internal validity: Naming our discovered topics is another threat that may impact the validity of our study,
especially since we performed our naming process manually. To minimize such threat we used independent naming
by three different authors, each with extensive experience in GraphQL development. Conflicts were resolved
through discussion. Additionally, we conducted second-level LDA experiments to identify subtopics within each
topic category. The subtopics help produce more insight into the contents of the topics rather than solely relying
on the top words within their respective parent topics. We also applied well-known techniques [23, 28] to validate
the topic names such as selecting random questions and answers from SO.
Construct validity: We consider our decision to utilize LDA to perform topic modeling a threat since LDA is
prone to stability and coherence issues [22]. To mitigate that we apply standard techniques [23, 28, 52, 56] in
conjunction with exhaustive experiments. For example, we repeat every single LDA experiment 10 times in order
to capture the results with the highest coherence values. We also ensure the stability of our repetitions by utilizing
the Jaccard similarity score. Deciding to include both the titles and bodies of the SO questions and answers as
opposed to only the titles poses another threat. Therefore, we employed well-known preprocessing steps to
cleanse the posts and help reduce the noise before qualifying the documents into our LDA system. Yet another
threat is determining the optimal number of topics K for both top-level and second-level LDA experiments,
especially since landing an optimal K value is cumbersome [28]. To minimize that, we exhausted all possible K
values in a brute-force fashion, stepping the number of topics by 1 each time, at the expense of experimentation
time and effort. Deriving a proper GraphQL reference architecture is also a threat which, in order to alleviate, we
applied standard reference architecture derivation techniques [40, 44, 63] and also utilized two concrete GraphQL
implementations. Sound mapping of topics to the respective architecture layers of the GraphQL ecosystem is a
threat due to variations in topic sizes and mapping cardinality. To reduce such a gap, we conducted second-level
LDA experiments and performed architecture mapping based on additional insights produced from the subtopics.
External validity: Using SO as the only source of our dataset is a threat that may compromise the external
validity of our results. However, SO is the most popular and goto place for software developers to find solutions to
technical challenges. Moreover, our dataset is large with approximately 45k of real-world questions and answers
to provide crucial insights.

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:30 • Amareen et al.

Conclusion validity: We conducted Anderson–Darling tests [27] to test normality of popularity and difficulty
measures. Since our results suggest non-normal distributions, we refrain from reporting potentially misleading
mean measures. Hence, we do not anticipate any threat arising from our statistical tests.

8 CONCLUSION
GraphQL is an emerging technology, aiming to serve as an alternative or coexisting API to legacy protocols
that dominated the industry for the past decade (e.g., REST). Due to its flexibility and efficiency, it has been
gaining rapid adoption among various industries [37]. With the goal of understanding challenges encountered
by GraphQL developers, we analyzed 45K StackOverflow questions and answers on GraphQL. We conducted a
mixed-method empirical analysis, where we leveraged LDA to automatically identify 14 topics and 47 subtopics.
We derive a reference architecture for the GraphQL ecosystem with five key layers based on two well-known
GraphQL implementations. Furthermore, we manually inspect questions on each topic and subtopics to create a
topic-to-architecture mapping and provide additional insight to the GraphQL stakeholders. Our results indicate
that Client and Server are the top two architectural layers attracting discussion on SO. While earlier discussions on
SO focused on building third-party applications consuming GraphQL APIs (i.e., API Integration) released by large
organizations, recent trends suggest more organizations implementing APIs using GraphQL servers. Discussions
on basic building blocks of GraphQL, such as Resolvers, Query & Mutations, GraphQL modeling, and Payload
Management are both popular and are better supported by the community. On the other hand, implementations
of new GraphQL servers, clients, managing subscriptions, and tooling have a lower level of support, although
those areas have high community interests. Due to difficulty and lack of well-defined solutions, security remains
difficult and low-interest area, which can lead to vulnerabilities [48, 66]. Hence, efficient implementation of
Security at various layers is a pressing research need.

DATA AVAILABILITY
We have made our dataset, source code, and results publicly available on GitHub at: [Link]
SEAL/graphql-topic-modeling

REFERENCES
[1] [n.d.]. Amazon AppSync. [Link]
[2] [n.d.]. Apollo GraphQL. [Link]
[3] [n.d.]. Apollo Server Intgrations. [Link]
[4] [n.d.]. DGS Framework. [Link]
[5] [n.d.]. Django, the web framework for perfectionists with deadlines. [Link]
[6] [n.d.]. Gatsby. [Link]
[7] [n.d.]. Gensim Python Library. [Link]
[8] [n.d.]. Gradle Build Tool. [Link]
[9] [n.d.]. Graphene Python. [Link]
[10] [n.d.]. GraphQL code libraries, tools and services. [Link]
[11] [n.d.]. Hasura, Instant GraphQL APIs on your data. [Link]
[12] [n.d.]. Introduction to Apollo client. [Link]
[13] [n.d.]. Introduction to Apollo federation. [Link]
[14] [n.d.]. Maven. [Link]
[15] [n.d.]. Prisma: Next-generation [Link] and TypeScript ORM. [Link]
[16] [n.d.]. Python GraphQL Schema-first. [Link]
[17] [n.d.]. Srping. [Link]
[18] [n.d.]. Stack Exchange Data Dump. [Link]
[19] [n.d.]. Stack Overflow. [Link]
[20] [n.d.]. StackExchange Sites. [Link]
[21] 2021. GraphQL Specification. [Link]

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
 GraphQL Adoption and Challenges: Community-Driven Insights from StackOverflow Discussions • 0:31

[22] Amritanshu Agrawal, Wei Fu, and Tim Menzies. 2018. What is wrong with topic modeling? And how to fix it using search-based
software engineering. Information and Software Technology 98 (2018), 74–88.
[23] Syed Ahmed and Mehdi Bagherzadeh. 2018. What do concurrency developers ask about? a large-scale study using stack overflow. In
Proceedings of the 12th ACM/IEEE international symposium on empirical software engineering and measurement. 1–10.
[24] Md Abdullah Al Alamin and Gias Uddin. 2024. How far are we with automated machine learning? characterization and challenges of
AutoML toolkits. Empirical Software Engineering 29, 4 (2024), 91.
[25] Md Abdullah Al Alamin, Gias Uddin, Sanjay Malakar, Sadia Afroz, Tameem Haider, and Anindya Iqbal. 2023. Developer discussion
topics on the adoption and barriers of low code software development platforms. Empirical software engineering 28, 1 (2023), 4.
[26] Saleh Amareen and Amiangshu Bosu. [n.d.]. GraphQL Replication Package. [Link]
[27] Theodore W Anderson and Donald A Darling. 1952. Asymptotic theory of certain" goodness of fit" criteria based on stochastic processes.
The annals of mathematical statistics (1952), 193–212.
[28] Mehdi Bagherzadeh and Raffi Khatchadourian. 2019. Going big: a large-scale study on what big data developers ask. Proceedings of the
2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering
(2019).
[29] Kartik Bajaj, Karthik Pattabiraman, and Ali Mesbah. 2014. Mining questions asked by web developers. In Proceedings of the 11th Working
conference on mining software repositories. 112–121.
[30] Anton Barua, Stephen W Thomas, and Ahmed E Hassan. 2014. What are developers talking about? an analysis of topics and trends in
stack overflow. Empirical software engineering 19 (2014), 619–654.
[31] Asma Belhadi, Man Zhang, and Andrea Arcuri. 2022. Evolutionary-based automated testing for GraphQL APIs. In Proceedings of the
Genetic and Evolutionary Computation Conference Companion. 778–781.
[32] Lauren R Biggers, Cecylia Bocovich, Riley Capshaw, Brian P Eddy, Letha H Etzkorn, and Nicholas A Kraft. 2014. Configuring latent
dirichlet allocation based feature location. Empirical Software Engineering 19 (2014), 465–500.
[33] Gleison Brito, Thais Mombach, and Marco Tulio Valente. 2019. Migrating to GraphQL: A practical assessment. In 2019 IEEE 26th
International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 140–150.
[34] Gleison Brito and Marco Tulio Valente. 2020. REST vs GraphQL: A controlled experiment. In 2020 IEEE international conference on
software architecture (ICSA). IEEE, 81–91.
[35] Alan Cha, Erik Wittern, Guillaume Baudart, James C. Davis, Louis Mandel, and Jim A. Laredo. 2020. A principled approach to GraphQL
query cost analysis (ESEC/FSE 2020). Association for Computing Machinery, 257–268.
[36] Partha Chakraborty, Rifat Shahriyar, Anindya Iqbal, and Gias Uddin. 2021. How do developers discuss and support new programming
languages in technical Q&A site? An empirical study of Go, Swift, and Rust in Stack Overflow. Information and Software Technology 137
(2021), 106603.
[37] Roy Derks. 2023. Seven key insights on GraphQL trends. [Link]
[38] Tomás Díaz, Federico Olmedo, and Éric Tanter. 2020. A mechanized formalization of GraphQL. In Proceedings of the 9th ACM SIGPLAN
International Conference on Certified Programs and Proofs. 201–214.
[39] Ian Fette and Alexey Melnikov. 2011. The websocket protocol. Technical Report.
[40] A. Grosskurth and M.W. Godfrey. 2005. A reference architecture for Web browsers. In 21st IEEE International Conference on Software
Maintenance (ICSM’05). 661–664. [Link]
[41] Junxiao Han, Emad Shihab, Zhiyuan Wan, Shuiguang Deng, and Xin Xia. 2020. What do programmers discuss about deep learning
frameworks. Empirical Software Engineering 25 (2020), 2694–2747.
[42] Olaf Hartig and Jorge Pérez. 2017. An initial analysis of Facebook’s GraphQL language. (2017).
[43] Olaf Hartig and Jorge Pérez. 2018. Semantics and complexity of GraphQL. In Proceedings of the 2018 World Wide Web Conference.
1155–1164.
[44] A.E. Hassan and R.C. Holt. 2000. A reference architecture for Web servers. In Proceedings Seventh Working Conference on Reverse
Engineering. 150–159. [Link]
[45] Sharron Helmke. 2022. WHERE DO YOU START WHEN EVERYTHING FEELS URGENT? Use an effort-to-impact matrix. The Learning
Professional 43, 2 (2022), 72–74.
[46] Stefan Karlsson, Adnan Čaušević, and Daniel Sundmark. 2021. Automatic property-based testing of graphql apis. In 2021 IEEE/ACM
International Conference on Automation of Software Test (AST). IEEE, 1–10.
[47] Georgios Mavroudeas, Guillaume Baudart, Alan Cha, Martin Hirzel, Jim A Laredo, Malik Magdon-Ismail, Louis Mandel, and Erik Wittern.
2021. Learning GraphQL query cost. In 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE,
1146–1150.
[48] Shae McFadden, Marcello Maugeri, Chris Hicks, Vasilios Mavroudis, and Fabio Pierazzi. 2024. Wendigo: Deep Reinforcement Learning
for Denial-of-Service Query Discovery in GraphQL. In IEEE Workshop on Deep Learning Security and Privacy (DLSP).
[49] Annibale Panichella, Bogdan Dit, Rocco Oliveto, Massimilano Di Penta, Denys Poshynanyk, and Andrea De Lucia. 2013. How to
effectively use topic models for software engineering tasks? an approach based on genetic algorithms. In 2013 35th International

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.
0:32 • Amareen et al.

conference on software engineering (ICSE). IEEE, 522–531.

[50] Maria Papoutsoglou, Georgia M. Kapitsaki, Daniel German, and Lefteris Angelis. 2022. An analysis of open source software licensing
questions in Stack Exchange sites. Journal of Systems and Software 183 (2022), 111113. [Link]
[51] Anthony Peruma, Steven Simmons, Eman Abdullah AlOmar, Christian D Newman, Mohamed Wiem Mkaouer, and Ali Ouni. 2022. How
do i refactor this? An empirical study on refactoring trends and topics in Stack Overflow. Empirical Software Engineering 27, 1 (2022), 11.
[52] Gustavo Pinto, Fernando Castor, and Yu David Liu. 2014. Mining questions about software energy consumption. In Proceedings of the
11th Working Conference on Mining Software Repositories. 22–31.
[53] Martin F Porter. 2001. Snowball: A language for stemming algorithms.
[54] Michael Röder, Andreas Both, and Alexander Hinneburg. 2015. Exploring the space of topic coherence measures. In Proceedings of the
eighth ACM international conference on Web search and data mining. 399–408.
[55] Piotr Roksela, Marek Konieczny, and Slawomir Zielinski. 2020. Evaluating execution strategies of GraphQL queries. In 2020 43rd
International Conference on Telecommunications and Signal Processing (TSP). IEEE, 640–644.
[56] Christoffer Rosen and Emad Shihab. 2016. What are mobile developers asking about? a large scale study using stack overflow. Empirical
Software Engineering 21 (2016), 1192–1223.
[57] Carson Sievert and Kenneth Shirley. 2014. LDAvis: A method for visualizing and interpreting topics. In Proceedings of the workshop on
interactive language learning, visualization, and interfaces. 63–70.
[58] Patrick Stünkel, Ole von Bargen, Adrian Rutle, and Yngve Lamo. 2020. GraphQL federation: A model-based approach. (2020).
[59] Minaoar Hossain Tanzil, Masud Sarker, Gias Uddin, and Anindya Iqbal. 2023. A mixed method study of DevOps challenges. Information
and Software Technology 161 (2023), 107244.
[60] Gias Uddin, Fatima Sabir, Yann-Gaël Guéhéneuc, Omar Alam, and Foutse Khomh. 2021. An empirical study of IoT topics in IoT developer
discussions on Stack Overflow. Empirical Software Engineering 26, 6 (06 Sep 2021), 121. [Link]
[61] Sri Lakshmi Vadlamani, Benjamin Emdon, Joshua Arts, and Olga Baysal. 2021. Can graphql replace rest? a study of their efficiency and
viability. In 2021 IEEE/ACM 8th International Workshop on Software Engineering Research and Industrial Practice (SER&IP). IEEE, 10–17.
[62] Daniela Meneses Vargas, Alison Fernandez Blanco, Andreina Cota Vidaurre, Juan Pablo Sandoval Alcocer, Milton Mamani Torres,
Alexandre Bergel, and Stéphane Ducasse. 2018. Deviation testing: A test case generation technique for graphql apis. In 11th International
Workshop on Smalltalk Technologies (IWST). 1–9.
[63] Zhiyuan Wan, Xin Xia, and Ahmed E. Hassan. 2021. What Do Programmers Discuss About Blockchain? A Case Study on the Use of
Balanced LDA and the Reference Architecture of a Domain to Capture Online Discussions About Blockchain Platforms Across Stack
Exchange Communities. IEEE Transactions on Software Engineering 47, 7 (2021), 1331–1349. [Link]
[64] Erik Wittern, Alan Cha, James C. Davis, Guillaume Baudart, and Louis Mandel. 2019. An Empirical Study of GraphQL Schemas.
In Service-Oriented Computing, Sami Yangui, Ismael Bouassida Rodriguez, Khalil Drira, and Zahir Tari (Eds.). Springer International
Publishing, Cham, 3–19.
[65] Xin-Li Yang, David Lo, Xin Xia, Zhi-Yuan Wan, and Jian-Ling Sun. 2016. What security questions do developers ask? a large-scale study
of stack overflow posts. Journal of Computer Science and Technology 31 (2016), 910–924.
[66] Shahriar Yazdipour. 2020. GitHub data exposure and accessing blocked data using the GraphQL security design flaw. arXiv preprint
arXiv:2005.13448 (2020).

ACM Trans. Softw. Eng. Methodol., Vol. 33, No. 0, Article 0. Publication date: 2024.