GraphQL: A Systematic Mapping Study

GraphQL is a query language and execution engine for web application programming interfaces (APIs) proposed as an alternative to improve data access problems and versioning of representational state transfer APIs. In this article, we thoroughly study the GraphQL field, first describing the GraphQL paradigm and its conceptual framework, and then conducting a systematic mapping study of 84 primary studies selected from an original set of 3,185. Our work analyzes trends or knowledge gaps about GraphQL by general classification of the studies and specific classification of this research topic. The study’s main conclusions show that GraphQL adoption is growing in the community as a strong alternative to implement APIs. However, we identified the need to strengthen the amount and rigor of empirical evidence collection in applied industry and government studies. In addition, we revealed the opportunity for specific studies on most GraphQL components, especially the consumption of GraphQL API services.


INTRODUCTION
Today, Software-as-a-service (SaaS) has received signiicant attention as one of the three main service models of cloud computing (i.e., Platform-as-a-Service or PaaS, and Infrastructure-as-a-Service or IaaS [33,54]).SaaS utilizes the internet to deliver applications to its users, which are managed by a provider.Therefore, selecting the best SaaS provider among those available is a critical challenge [46].This challenge falls on software architects who must build reliable and eicient SaaS that overcome the signiicant technical and functional problems of cloud applications, such as multi-tenancy, redundancy, recovery, or scalability [54].In order to overcome these challenges, the microservices architecture represents a clear trend both in academia and industry [29], where large companies worldwide have evolved their applications towards this architectural style [8].
Speciically, the Microservices Architecture (MSA) is composed of small applications (microservices) with a single responsibility (functional, non-functional, or cross-functional requirements) that can be independently deployed, scaled, and tested [2,53].Microservices can be developed and modiied independently using diferent programming languages and product stacks, thus supporting agility [2,23].Its main advantages are maintainability, reusability, scalability, availability, and automated deployment [29].Microservices communicate through lightweight mechanisms, typically using the Representational State Transfer (REST) architectural style to build application programming interfaces (API)s named REST APIs.Software organizations have rapidly adopted REST APIs in the development of their applications after its creation in 2000 [56].
REST is the most widely used paradigm in microservices development [61].However, despite its popularity, it presents some data access issues, such as: (i) query complexity (i.e., REST requires multiple HTTP requests to obtain multiple resources); (ii) over-fetching (i.e., a REST request returns more data than an application needs); and (iii) under-fetching (i.e., a particular endpoint does not give enough information, so additional requests must be made to obtain the required information), which is also known in the literature as the n+1 request problem [34,55].To illustrate the over-fetching and under-fetching problems found in REST microservices, we consider a scenario of consuming a REST API and a GraphQL API of blogs [44].In this scenario, a client application needs to query post titles of a speciic user and the names of the last three followers of that user, see Figure 1.
Fig. 1.Example of over-fetching and under-fetching in REST API vs. GraphQL API [44] On the one hand, Figure 1, a) shows the request and response to the REST API.REST usually collects the data by accessing various resources (aka endpoints).For the proposed scenario, it is necessary to query data at three endpoints: /users/<id> to get the user's data, secondly, /users/<id>/posts for the user's posts, and the third endpoint /users/<id>/followers, which returns a list of followers per user.On the other hand, Figure 1, b) shows the request and response to the GraphQL API.Using this paradigm, the user can send only one query asking for the speciic data it needs, then the server responds only with the requested data [44,55].The under-fetching in REST surfaces when the request needs to access three endpoints to get the data requirements it needs, while GraphQL needs only one access to get the required data.In turn, over-fetching in REST occurs when each endpoint access gets more data than it needs, while GraphQL only gets the requested data.
In the last decade, some query languages such as SPARQL 1 , Cypher2 , Gremlin 3 , and GraphQL have emerged as alternatives for API data access [50].In this study, we focus on GraphQL because there is a growing interest in the industry since it has proven to be an alternative to solve the problems found in traditional REST technology [50,55].GraphQL started in 2012 as an internally developed speciication on Facebook.In 2015, they decided to share GraphQL with a broader community [28], releasing both an open source speciication and a reference implementation through the graphql.org4community [12].Since then, the community has grown, as well as the adoption in the production environment by hundreds of organizations of all sizes, such as Atlassian, GitHub, Netlix, The New York Times, and Twitter, among others [28,36].In this work, we evidence an average annual growth of 16.67% between 2015 and 2020 in the number of studies published in scientiic literature databases related to software engineering.In the same sense, we show an average annual growth of 13.61% in the search trend of the term "graphql", reported in Google Trends (see Section 3.1).Despite the growing interest in GraphQL, there is no global vision that helps new researchers know the principal existing research proposals, the studies' scope, trends in the research approach over time, or existing gaps in scientiic evidence.This work's objective is twofold: irst, to introduce the novel GraphQL paradigm through illustration, exempliication, and conceptualization of its components.Then, to conduct a systematic mapping study (SMS) of GraphQL to establish an overview of the subject through a publication classiication scheme and structure the scientiic community's ield of interest.The rest of the paper is structured as follows.In Section 2: we establish the GraphQL paradigm.Next, Section 3 shows how we conducted the systematic mapping study (SMS).Then, in Section 4 we present the results obtained from the SMS.Afterwards, we analyze and discuss the main indings of our study.Finally, Section 6 summarize the conclusions of the study.

GRAPHQL PARADIGM 2.1 GraphQL Foundations
Its formal speciication deines GraphQL as a query language and execution engine to describe the capabilities and requirements of data models for client-server applications [52].To implement GraphQL application servers (GraphQL APIs), it is not necessary to use a speciic programming language or persistence mechanism.Instead, GraphQL encodes in a uniform language the model capabilities of a type system based on ive design principles: hierarchical, product-centric, strong-typing, client-speciied queries, and introspective [12,52].
In the following, we present the GraphQL paradigm, illustrating the conceptual and functional structure of the GraphQL formal speciication 5 (June 2018 release).We begin to structure the paradigm by showing the interaction between the high-level components of GraphQL (language and its grammar, type system, introspection, and execution and validation engines).Figure 2 shows that the interaction starts in (1) the development-time tools that use the GraphQL language, its grammar, and IDL (Interface Description Language) to deine and generate the type system or type system extensions of the GraphQL Service.(2) The generation of the service (GraphQL API) is complemented by generating type system Resolvers using some programming language.Then the service generated from the customer tools is consumed.(3) A document with executable operation deinitions (query, mutation, subscription) or fragments is created to send an execution request to the GraphQL service.Before sending the request, the client tools provide a syntax validation using the GraphQL service's introspection (represented with the "INT" bubble in the "Client tools" section).The GraphQL service receives the request and validates that the document contains only executable deinitions for execution.Running the GraphQL service obtains the requested data from the Type System and Resolvers.(4) The GraphQL service execution sends the result as a response document (usually in JSON format) to the client tools.The response document also includes error messages if there are errors during execution.

Type System Definition
Schema, Types, Directives

SchemaExtension, TypeExtension
GraphQL Service Once explained how the four high-level components work and interact, in the next Section 2.2 we complete their structure and technical description of seventeen speciic components of the GraphQL paradigm.

GraphQL language.
The GraphQL language provides a comprehensive syntax to create documents that can contain either the type system deinitions of GraphQL services or the actual queries clients execute on them.Thus, a GraphQL document can contain diferent deinition instances (type system, type system extension, or executable) [52].Figure 3 shows each type of deinition's main components; they will be detailed and exempliied in the following.Besides, GraphQL language includes an IDL (Interface Description Language) used to describe the type system of a GraphQL service used by the tools to provide utilities such as client code generation or service bootstrapping [52].

DocumentDefinition
Type System Deinition.Deines the data capabilities of the Type System of a GraphQL server, as well as the input types of the query variables.A GraphQL Document containing a TypeSystemDeinition must not be executed by GraphQL execution services.We illustrate the conceptual structure and the interaction of the components of the type system deinition in Figure 4.The main components are described in the following.Schema conforms the collective-type system capabilities of a GraphQL service.Their deinition is in terms of types and directives, as well as the root operation types for each kind of operation: query, mutation, and subscription.Types are the fundamental unit of the GraphQL schema.Concrete types can be deined based on six named types and two wrapping types.The "named types" are: • Scalars: represent a primitive value, like string, integer, loat, boolean, or a unique identiier (ID).
• Enums: describe the set of possible values.
• Objects: deine a set of ields where each ield is also of a type in the system.Fields are conceptually functions that return values and occasionally accept arguments that alter their behavior; these arguments are usually mapped directly to a function within a GraphQL server implementation.Therefore, response trees are composed of leaves of type Scalars and Enums, and intermediate levels are of type Objects, thus allowing arbitrary type hierarchies to be deined.• Input objects: deines a set of input ields; it can be scalars, enums, or other input objects.In turn, among "named types" there are two abstract types that must irst resolve to a relevant "named type" object: • Interfaces: deine a list of ields.
• Unions: deine a list of possible types.Finally, we refer to wrapping types as those that efectively wrap or contain a "named type": • List: a GraphQL schema may describe that a ield represents a list of other types; for this reason, the list type wraps another type.• Non-null: wraps another type and denotes that the resulting value will never be null.Directives provide a way to describe alternate runtime execution and type validation behavior in a GraphQL document.Directives can be used to describe additional information for types, ields, fragments, and operations.
Next, we complement the conceptualization of the GraphQL paradigm speciication with illustrations and examples of its components.For this purpose, we implement a Star Wars API GraphQL service that shows the movies' basic structure and characters.Figure 5 shows some examples containing the essential components of a type system deinition [51]: a) deines the GraphQL service schema with the available operations (query and mutation); b) deines the query types (humans, droid), which receive scalar type arguments and return a list of type objects; c) deines the mutation (createHuman), which receives an input type argument and returns an object type; d) deine the enum type (Episode), which speciies a set of values; e) deines the type object (Character) that contains a set of ields.The symbol (!) in the appearsIn ield means that it does not accept null values; f) deines the type Interface (Character) that contains additional ields to the type object Character; g) deines the implementation (Human) of the interface (Character) that contains the ields of the interface and an additional ield (totalCredits); h) deines the implementation (Droid) of the interface (Character) that contains the ields of the interface and additional ield (primaryFunction); i) deines the input object (HumanInput) that contains a set of ields used in the createHuman mutation; and j) deines SearchResult as a union type used to search for data in Human or Droid types.
Type System Extension.Represents a GraphQL type system that extends from an original type system.This construct can be used, for example, by a local service to represent data that a GraphQL client only accesses locally, or by a GraphQL service that is itself an extension of another GraphQL service.Figure 6 shows an example of an Object type extension that represents a Character type that has been extended from the original type (see Figure 5), which also adds a local data ield.Executable Deinition.Executable documents are deined by operations or fragments [52].Figure 7 shows the relationship and conceptual structure of their components.In the following, we describe the components of executable deinitions.
Operations are the main elements of executable deinitions, and can be either (i) queries, which are readonly and fetch data; (ii) mutations that irst write and then fetch data; and (iii) subscriptions, which are long-running requests that fetch data in response to events from the source.Variables are introduced to maximize the reusability of GraphQL queries parameterized with variables, avoiding costly string building in clients at runtime.Input Values can be scalar values, enumeration values, lists, or input objects.Directives are used in a similar way as in the Type System components.Arguments alter the behavior of ields that occasionally accept them.Function arguments are often mapped within a GraphQL server implementation.Selection Sets are primarily composed of ields.Their purpose is to restrict requests to select only the needed subset of information, avoiding over-fetching and under-fetching data.Fields describe the discrete information available and can represent complex data or relationships with other data; they are also considered conceptual functions that return values.Fragments are the basic unit of composition in GraphQL that allows reusing of commonly repeated selections of ields.Figure 8 shows examples of the most used operations (queries and mutations) of the executable deinition [51] concerning the type system deined in Figure 5, namely: a) deines the operation (NewHumans) that executes the mutation (createHuman).It also shows three ways to execute the type of query (humans); b) executes the query but without deining the name of the request; c) deines the request (queryOneHuman) that executes the query "humans" that receives parameter "id" with the value of one, which means that the query will return the record that has that identiier; and d) deines the request (queryWithFragment) that executes the query using the fragment (FragmentTwoFields) that refers to a set of speciic ields of the implementation (Human).Client tools are responsible for sending these deinitions to the GraphQL service which will execute the requests.when the execution has found an error.The extension is reserved for implementers to extend the protocol without content restrictions [43,51,52].Figure 9 shows the response to requests for execution of the mutation and query operations carried out in Figure 8.

Introspection.
A GraphQL server supports the introspection of its schema by querying the type system using the same GraphQL language [52].Figure 10 shows a) the introspection query to the type system (Figure 5) and b) the query's answer.GraphQL veriies if a request is syntactically correct and ensures that it is unambiguous and mistake-free in a given GraphQL schema.The validation is performed before execution.However, a GraphQL service may execute a request without explicitly validating it if that exact same request is known to have been validated before.GraphQL execution will only consider the executable deinitions of Operations and Fragment.
Type system deinitions and extensions are not executable and therefore are not considered during execution [52].
2.2.5 Execution.GraphQL generates a response to a request via its execution facility in the context of the universe of data available in a schema provided by the appropriate GraphQL service.Only requests that pass validation rules are actually executed; if it has validation errors, they will be reported in the list of łerrorsž within the response, and the request will fail without execution [52].It is worth mentioning that there are cases of requests that pass the validation, but during the execution present data errors, in those cases, the execution returns the data result, but also returns the description of the error occurred.Each ield of each type is backed by a function called the resolver which the GraphQL server developer has to provide.When a ield is executed, the corresponding resolver is called to produce the response value [43,52].

RESEARCH METHOD
In software engineering, two techniques are clearly distinguished for carrying out studies of the literature that serve to structure knowledge systematically and reproducible, namely systematic mapping studies and systematic literature review [26].
On the one hand, a Systematic mapping study (SMS) is a method for constructing a classiication scheme for topics studied in a ield of interest.By counting the number of publications for categories within a scheme, the coverage and maturity of the research ield can be determined.The results are presented on graphical maps showing the number of publications in diferent categories.Mapping studies generally cover a more extensive range of publications as the analysis focuses on summaries and key terms [40].
On the other hand, a Systematic literature review (SLR) is a means of identifying, analyzing, and interpreting reported evidence related to a set of speciic research questions in an unbiased and (to some extent) repeatable manner.Unlike mapping studies, systematic reviews generally cover a smaller and more speciic range of publications, while the analysis focuses on the details of published contributions [25].

Need for a systematic mapping study
We approached the need for this study from the point of view of the scientiic and industrial community.On the one hand, concerning the scientiic community, we searched for SLRs or SMSs studies on GraphQL in the most used scientiic literature databases related to software engineering: ACM Digital Library6 , SpringerLink7 , IEEE Xplore Library8 , Scopus9 , Google Scholar10 , and DBLP 11 [9,25,26]; where we veriied that there is no study of this type in the scientiic literature.Then, we veriied the GraphQL study trend by conducting a survey on the frequency of research in bibliographic databases from 2015 (GraphQL release to the community) to 2021 (last full year).Wherein, Figure 11 shows the trend of publications by year, tabulating the number of publications related to GraphQL, which are normalized in the igure by using the yearly percentage distribution of total publications about GraphQl during the 2015-2021 period in a given database (%T.).We evidenced an average growth of 66% by calculating the percentage variation [31] by year.
On the other hand, regarding the industrial community, Figure 12 sums up the trend of search interest for the term "graphql" using the Google Trends tool 12 ; where the search interest is scaled on a range from 0 to 100 based on the proportion of searches for the topic [20].Although the last two years show a slight decrease, the overall average of the yearly percentage variation calculation [31] increases 98%.
In summary, we found that the scientiic and industrial communities have shown increasing interest in GraphQL, but to the best of our knowledge, there are still no literature reviews to provide an overview of the study of GraphQL.As a result, we found the need to conduct an SMS to establish an inventory of classiied primary studies (i.e., studies that obtain empirical evidence on a topic of interest [19]) to provide an overview that allows researchers to discover gaps and trends about the study of GraphQL.

SMS process definition
The process for conducting SMS (summarized in Figure 13) was established based on the guidelines proposed by Petersen in 2008 [40], Petersen 2015 [42], and Kuhrmann 2017 [26], which consists of the following phases:

Phase 1: planning the mapping
This section plans the process for conducting the mapping and will serve as a guide for executing or reproducing this work: Identiication of need and scope: The systematic mapping study aims to provide an overview of the scientiic community's production and ind knowledge gaps around the GraphQL paradigm.The SMS will perform a topic-speciic classiication about GraphQL and a topic-independent classiication to identify the trend, evolution, empirical evidence maturity, and types of research publications based on the facets of Petersen et al. [1,40,42].
To deine the research questions that guide the SMS, we use Kipling's 5W+1H model [24] to abbreviate the questions: Who, Why, What, Where, When, and How.This model is used to know the most important aspects of a story (commonly used in journalism) [14,24].Applying the model, we formulated the following research questions (RQ): RQ1: Who are the authors and institutions researching about GraphQL?The purpose is to identify which authors and institutions are researching this topic to encourage collaboration.RQ2: Where were the research papers published?We will deine publication venues to identify the acceptance and impact of research on the GraphQL paradigm.RQ3: What is the empirical evidence maturity of the publications on the GraphQL?We will establish what research methods authors use to gather empirical evidence and what types of research were used to verify the maturity of the research topic.RQ4: When were the research papers published?This question attempts to show the trend and evolution over time of research on the GraphQL paradigm.RQ5: Why was the GraphQL paradigm studied?This question aims to discover why and in what contexts the scientiic community studied the GraphQL paradigm.RQ6: How was GraphQL introduced to the scientiic community?We will classify the type of contributions and the domain of their implementation.We will also identify the components of GraphQL that are most and least used in the research, thus establishing a vision for future research.RQ7: What are the frontiers of the research on GraphQL?This question abstracts the main indings presented in the studies and the open questions posed as future work.

Phase 2: Study identification
This section details how we identiied the primary study dataset for mapping, see Fig 14.
Search Strategies: We chose two strategies, the irst being an automatic search in the databases and then supplemented with manual searching to add relevant studies that did not appear in the irst search.The steps we established for the search are: 1) Conduct the search for primary studies using a search string in the databases chosen for the study; then apply the irst study ilter using the databases' automatic ilters.After that, using bibliographic reference management tools (e.g., Zotero and Mendeley), we merge the studies into a homogeneous structure.We inalized this step by removing duplicate studies.2) Filter the studies by applying inclusion and exclusion criteria.3) To improve the quality of the primary study dataset, we initially piloted the snowballing search strategy [58] but found no new publications that met the inclusion criteria of the study iltering.Therefore, we followed the recommendations of Wohlin [58] to use the manual search strategy to add relevant studies to the dataset.4) Finally, evaluate the search.
Conducting search: To establish the search string, we use the interactive improvement approach by identifying keywords from known papers.We decided to establish the search string with the word "graphql" to cover everything reported in the scientiic community since 2015, when GraphQL was released to the community, until June 30, 2021.We identiied that the appropriate scientiic population to consult for primary studies is the scientiic literature databases commonly used in software engineering: ACM Digital Library, Springer Link, IEEE Xplore Library, Scopus, DBLP and Google Scholar [9,25,26,42].We began conducting the automatic search in the databases and obtained a total of 3185 studies.After that, we searched again and applied the databases' Step 2: Filtering Studies Fig. 14.Process followed to identify the primary study dataset automatic ilters (see TI, TA, EO, NC, and NA in Figure 14), obtaining 254 studies.Then, we removed duplicate studies obtaining an initial dataset of 135 studies.
Filtering Studies: In this step, we deine and apply the inclusion and exclusion criteria on the study's initial dataset to establish the relevance of the research topic [27,42].
Inclusion criteria: • Publications in English that have been peer reviewed in journals, conferences, or workshops.
• Gray Literature (evidence not controlled by commercial publishers) can include academic papers, including theses and dissertations [38], such as Bachelor's, Master's, and Ph.D. theses.• Publications from 2015 to 2021.
• Publications that focus on the use of the GraphQL paradigm in the title and the abstract.
• Publications that contain a reasonable context, objectives, and research method.
• Publications that refer to GraphQL (homonyms name) proposed by Huahai He and Ambuj Singh in 2008 (HOM).It is a graph query language that allows lexible manipulation of graph structures.In addition, they introduce the notion of formal languages for graphs (useful for the deinition of graph queries as well as database graphs) [22].• Publications that solely reference GraphQL as an external citation (OREF) and they do not use or extend the paradigm (Section 2.1).• Publications not available through our institutions' subscriptions or in open repositories (AVA).
After applying the inclusion and exclusion criteria, we obtained a dataset of eighty studies Manual search: We complemented the search strategy with the manual search method; we found four studies in the results of the automatic searches before applying the automatic ilters in the databases; this resulted in a dataset of 84 primary studies.
Evaluation of the search: Petersen [42] and Kitchenham [25] recommend maintaining a low stringency in evaluating the quality of primary studies because SMSs aim to provide an overview of the research topic area.For this reason, we decided not to exclude any primary studies in this section, resulting in a dataset of eighty-four primary studies for mapping.

Phase 3: Data extraction and classification
In this phase, we extracted data from the primary studies to conduct a general classiication that does not depend on the researched topic (topic-independent classiication) and another speciic classiication about the GraphQL paradigm (topic-speciic classiication) [42].
Topic-independent classiication scheme: The following describes the ields of data extraction based on the facets, venue, research type, research method, and study focus proposed in Petersen et al. [42]: Title: title of the publication, specifying the study, use, or extension of the GraphQL paradigm.Abstract: summary of the publication, specifying the study, use, or extension of the GraphQL paradigm; do not use the term GraphQL only to reference an external citation.Authors: principal author (irst author) and co-authors of the publication.Authors' ailiation: irst ailiation of the publication's authors.Countries: country of authors' ailiation.Year: year of the publication.Venue: name of publication venue.Venue types: peer-reviewed venues such as journals, conferences, and workshops [42].In addition, we added gray literature such as academic articles, theses, and dissertations to reduce possible publication bias and provide a more balanced view of the evidence [38].
Venue rate: impact factor of the venue types measured with Scimago Journal & Country Rank (SJR) 13 , Journal Citation Reports (JCR) 14 , and GII-GRIN-SCIE (GGS) Conference Rating 15 .SJR calculates the Scimago Journal Rank (SJR) impact factor of journals and countries based on information from the Scopus database (Elsevier B.V.) [48], measures the weighted citations of a journal according to the scientiic area and the relevance of the citing journals [49].Journal subdisciplines are ranked into four quartiles (Q1 to Q4) using the SJR Citation Index [11].JCR is an ISI Web of Knowledge product that provides a rich array of citation metrics such as the Journal Impact Factor™ (JIF) [5].A journal's quartile ranking (Q1 to Q4) is determined by comparing a journal to others in its JCR category based on JIF [6].GGS is an initiative that provides a uniied rating of computer science conferences [37], see Table 1.Opinion papers, these studies contain the author's opinion on a particular issue without relying on related research papers and methodologies.Research methods: Petersen et al. [42] identify that the types of "evaluation research" and "validation research" need empirical evaluation by using diferent research methods frequently applied in software engineering [10,21,57,60]; in this sense, we analyze and use the following subset of research methods proposed by [42]: Survey, identify the characteristics of a broad population of individuals.It is most closely associated with the use of questionnaires for data collection [10].Case study, investigate a single entity or phenomenon in its real-life context within a speciic time-space [60].Controlled experiment, investigates a testable hypothesis where one or more independent variables are manipulated to measure their efect on one or more dependent variables [10].Simulation, is a powerful technique to handle the complexity of the Legend applies condition: T=True, F=False, and •= irrelevant or not applicable.model (hundreds of dynamic variables and causal linkages).The use of simulation enables managers to assess quickly and safely the implications of an intended policy before it is implemented [30].Prototyping, is an approach based on an evolutionary view of software development and an impact on the development process.It involves producing early working versions (prototypes) of the feature application system and experimenting with them [4].Mathematical analysis, covers the basic techniques to identify a set of reasoning rules in a precise (and therefore mathematical) way in the system under study [3].Study setting: the context in which the study was conducted, whether in academia, industry, or government [7].In this sense, we established the following semantics "Academic": studies performed in synthetic environments that do not implement solutions for public use; "Industry" and "Government": studies conducted in industry/government practice environments or they expose solutions for public service.identify the Provider and Client domains.The Provider domain is any contribution implemented in the "GraphQL service" see Figure 2, and the Client domain is the contributions consuming the GraphQL service, see "Client tools" in Figure 2. Contribution type: it is a high-level classiication of GraphQL technical contributions.We deine the following semantics to identify and classify contribution types: Implementation, refers to studies that use the GraphQL paradigm to implement software.Analysis, refers to studies that contribute a comparative analysis or theoretical review to identify ways to apply the GraphQL paradigm.Integration, refers to studies that present the integration of GraphQL with other technologies to design or build integrated solutions.Extension, refers to studies that propose a new component or functionality in the GraphQL paradigm.
Applications, refer to studies that propose solution approaches applying the GraphQL paradigm but without its implementation.GraphQL Components: based on Section 2, we established the classiication by "Service" with its components: Execution, Introspection, Resolvers, Type System, Validation."Type System Deinition" with its components: Directives, Enums, Input Object, Interfaces, Objects, Scalars, Schemas, Unions."Execution Deinition" with its components: Fragments, Mutations, Query, and Subscription.Public API: The actual public APIs used in the publication, e.g., as a use case or supporting system.Consequently, we established the structure for data collection in this study based on the research questions presented; for each question, as shown in Table 3, we deine a set of ields derived from the topic-independent classiication, topic-speciic classiication, and minimum data structures recommended by Kuhrmann et al. [26] and Petersen et al. [42].

Validity evaluation
In conducting the SMS, we tried to be as methodological as possible; therefore, we evaluated the validity based on the guidelines of [41,42], using the following considerations: Descriptive validity is the description with precision and objectivity.We minimize this threat by introducing decision criteria forms for general categorization and classiication based on the Petersen guide [42] (see Section 3.5).We also introduced topic-speciic classiication criteria based on the GraphQL paradigm components exposed in this paper (see Section 2).Theoretical validity determine the ability to capture what we intend to capture [42].To minimize this threat, in the Study Identiication, we established the search string only with the word "graphql" to obtain an adequate sample concerning the target population.We also chose two strategies for the search: we started with the database search; we complemented it with the manual search strategy, where we found four studies that we added to the initial study dataset.We tried to minimize the risk of bias in data extraction and classiication when the irst researcher performed an individual mapping followed by a second researcher's review.Diferences found were validated by a joint reading of the full text of the publication and then discussed to a consensus based on the established rules for classiication in Section 3.5.Generalizability, according to Petersen and Gencel [41], should be considered internal generalization (within a population) and external generalization (between diferent populations).Internal validity ensures that a researcher's experimental design closely follows the cause-and-efect principle; therefore, in this study, we followed most of the methodological recommendations exposed by Petersen's guide [42].However, the existence of manual classiications in the process exposes us to introduce some study selection errors.Therefore, we considered a wide range of papers (including the gray literature) and introduced methods of decision criteria in the classiications to minimize this impact.External validity measures the applicability of the study results to other situations, groups, or events (generalizability).We tried to minimize this threat by using the Petersen et al. guide [42], which is very popular for conducting SMSs in software engineering.Besides, we conducted the speciic classiication of GraphQL components using the GraphQL paradigm based on the oicial site of the formal GraphQL speciication.Interpretive validity is when the conclusions are drawn reasonably, given the data.
We minimize the threat of bias in interpreting the conclusions by exposing the results described by the irst author, then reviewed separately by the three co-authors, and then discussed together in consensus meetings to unify revisions and interpretations.Repeatability requires detailed information on the research process.In this study, we report in detail the SMS process, expose the work iles in digital repositories, and explain the measures taken to reduce possible threats to validity.

RESULTS
In this section, we answer the research questions (RQ) established in Section 3.3 using the results of the data extraction process from the primary studies conducted in Section 3.5.The list of the primary studies is available in the supplementary material of the paper [45], where the 84 studies are coded from study "S01" to study "S84".

RQ1: Who are the authors and institutions researching about GraphQL?
In this question, we discovered the most active researchers and institutions that researched the GraphQL paradigm.
On the one hand, we show the authors' information who used the GraphQL paradigm in their publications.We considered the publication's irst author as the principal author and the other authors as co-authors, obtaining 298 authorships in the publications (84 main authorships and 214 co-authorships) corresponding to 270 researchers.
Figure 15 shows a summary of authors by country and continent; we observe that authors ailiated with European institutions lead the number of contributions with 60.74%; however, the United States is the country with the most authors, followed by Germany, which highlights the number of authorships of the principal authors.Table 4 shows the authors with the highest number of publications.
On the other hand, we show the institutions of the authors' ailiation.Figure 16 shows the institutions with two or more publications; the others are grouped in "Others".There are 86 institutions from 33 countries, where the Linkoping University of Sweden contributed the highest number of publications, followed by the Aalto University of Finland, IBM Research of United States, and RWTH Aachen University of Germany.This question identiies the venues, venue types, publication types where GraphQL studies were published, and their impact.In this sense, we started by identifying and ordering the following venue types according to the rigor of the review of publications; it is worth mentioning that we considered the gray literature to verify the interest of academia in the study of GraphQL.The publication types found at the venue are bachelor's and master's theses, workshop papers, conference papers, and journal papers.However, in conferences and workshops, we identiied two ways of publishing their studies; the irst is to publish the studies in the proceedings of the venues, and the second way is to publish the proceedings in a journal volume so that the impact of the journal catalogs the impact of their studies.Therefore, we subdivide conference and workshop papers whose proceedings are published in a journal: conference paper (journal) and workshop paper (journal).The following shows the publications' impact was measured by: GII-GRIN-SCIE (GGS), Scimago Journal & Country Rank (SJR), and Journal Citation Reports (JCR).In this section, we clarify that the impact of the gray literature is not measurable; therefore, the analysis of papers from workshops, conferences, and journals.Table 5 shows the workshop papers and their impact measured in GGS and SJR.The Workshop on (Constraint) Logic Programming (WLP), published in the journal Electronic Proceedings in Theoretical Computer Science, is highlighted with an SJR:0.33.
Table 6 shows the conference paper impact measured with GGS and SJR.According to the SJR metrics, on the one hand, the conferences that index their proceedings directly in Scopus have an SJR index but no quartile; in this segment, the leading conference is SANER (SJR: 0.29).On the other hand, conferences that publish their proceedings in volumes of journals indexed in Scopus generally have SJR and quartile indexes.In this segment, the leading conferences are CAISE, ICSOC, ICWE, and MEDI, published in the journal "Lecture Notes in Computer Science", which has quartile 2 (Q2) and SJR: 0.43.According to the GGS metrics, 19 of the 39 conference papers  Table 7 shows the journal articles' impact measured with JIF of JCR and SJR metrics.The highest quartile 1 (Q1) journals are Journal of Molecular Biology (JIF: 5.47, SJR: 3.19), Journal of Cheminformatics (JIF: 5.32, SJR: 1.43), and IT Professional (JIF: 3.70, SJR: 0.63).

RQ3: What is the empirical evidence maturity of the publications on the GraphQL?
This question identiies the maturity of the empirical evidence of the studies by classifying the publications' rigor; therefore, we classiied the publications by the research type according to the criteria indicated in Table 2 and identiied the research methods (see Section 3.5) used to support their GraphQL paradigm indings.Table 8 shows the publications by research type and methods.Figure 19 shows the research methods used in "evaluation" or "validation" research; where it is noticeable that the case study is the most commonly used research method in software engineering practice (i.e., evaluation research).In contrast, the most commonly used methods were experiments and prototypes in validation research.This question shows the evolution of GraphQL publications from 2015 to June 30, 2021.We consider the studies since 2015 because that is the year GraphQL was launched to the community.

Publications by Resea rch Type
Figure 20 shows the number of studies by type of research and year of publication.Again, we observe that the growth of publications is constant over time, with 2019 being the year with the highest growth (17.86%)compared to 2018.Note that publications of research types that present empirical evidence also increased over the years ("validation" and "evaluation" research types).Thus, although GraphQL is a young research topic and maintains a growing trend, the scientiic community should generate more studies with empirical evidence to improve and mature the knowledge base about GraphQL.

RQ5: Why was the GraphQL paradigm studied?
With this question, we try to determine why researchers conduct studies on GraphQL; in this sense, we assume Petersen's recommendations [42] to answer the question with the following metrics: study setting, application domain, and software engineering knowledge areas based on the SWEBOK.Figure 21 shows the publications by study environment and application domain.Most publications (71.43%) were in the academic context and the rest in the industrial context; we did not ind applied studies in the governmental context.We also calculated that the predominant application domains were development (52.38%) and computing (21.43%); this indicates that the academic world began to study the technical components of the GraphQL paradigm before applying them to other disciplines or sciences.9 show the classiication of publications by software engineering (SE) knowledge areas based on SWEBOK (see Section 3.5) used in their studies.Note that the knowledge area "construction" is the most applied (55.95%), followed by far by "computing foundations".These results of the knowledge areas match and are complemented by the results of the application domains, ratifying the interest of researchers in the study and technical application of the GraphQL paradigm.

RQ6: How was GraphQL paradigm introduced to the scientific community?
We answer this question by identifying speciic classiications of the use and application of the GraphQL paradigm based on Sections 2 and 3.5.In the data extraction and classiication phase, we identify the following categories:
Contribution type: This is a high-level classiication of GraphQL technical contributions in publications.Similar to the previous segment, we found publications that provided multiple contribution types; thus, we classiied 127 technical contributions from 84 publications.Table 11 shows the classiication of publications by contribution type and technical contribution, and Figure 24 shows that the most frequent contribution types were implementation and analysis.
Contributions: These are the speciic technical contributions using the GraphQL paradigm in the publications.Figure 24 shows that most of the contributions are of the "Implementation" and "Analysis" types; therefore, we will now analyze these two contributions.

Contribution Domain
GraphQL Limitations.Five publications have mentioned more clearly the inherent limitations of GraphQL in Data management: "schemes" do not support private ields and are therefore visible to client applications [S24]; large schemes suggest a degree of complexity in their comprehensibility for implementing complex queries, and there is the probability of object name collisions [S75]; in the study [S10] showed that 39.73% of schemes have at least one cycle in a sample of 2094 APIs, which could afect the efectiveness and eiciency of data handling."Security" should be managed to avoid excessive data queries or request overloads leading to a denial of service [S22, S75]."Cache" handling does not follow the HTTP speciication, instead using a single endpoint [S24], which is corrected by implementing a cache management library, but data invalidation must be managed [S04].Concerning "mutations", GraphQL does not support polymorphism (does not inherit input objects), ields may or may not be updated when receiving a null value, and there is a diference between input and output data formats [S75].With respect to the SE Process, the interoperability between co-existing REST and GraphQL endpoints in turn limits maintainability and separation of concerns [S04, S75].
GraphQL Challenges.With respect to the comparison with REST and SOAP area, the studies identify the need to conduct extensive studies of the quality characteristics in dynamic, parallel queries [S02, S43] in diferent networks, programming languages, query languages, and databases [S29, S34, S77, S78, S80] but subject to a scale and data complexity according to the industrial context, in order to establish the appropriate conditions for the use of these architectures.Focusing on data management, we highlight the following key challenges:

ANALYSIS AND DISCUSSION
In this section, we analyze and discuss the diferent relationships between the results obtained in the SMS.Before starting, we clarify that the general classiication results of the publications (topic-independent classiication) are in RQ1, RQ2, RQ3, RQ4, RQ5, and the speciic classiication about the GraphQL paradigm (topic-speciic classiication) in RQ6 and RQ7.
In RQ1 (Section 4.1), we observe that institutions from Europe are leaders in the study about GraphQL and have the majority (60.74%) of publications, followed with a signiicant distance by the other continents.However, we note that there is not yet any scientiic community specialized in this topic, although we highlight the contributions of Linkoping University.
In RQ2 (Section 4.2), we identiied that 46.43% of the publications are conference papers, followed by gray literature, journal articles, and workshops.Figure 27 shows the relationship of RQ2, RQ3, and RQ5 results to analyze the research types contributed by the venues; we conclude that including the gray literature in the SMS was a correct decision because 53.84% of its production provided evaluation and validation research.Although GraphQL is a young topic, we highlight publications in top-level conferences such as WWW (Class 1: A++) and ESEC/FSE (Class 1: A+) and Quartile 1 journals such as Molecular Biology, Cheminformatics, and IT Professional.In RQ3 (Section 4.3), we identiied that most of the publications are of validation or evaluation research type (61.91%), presenting a certain degree of maturity in empirical evaluation in their studies; however, only 17.86% of these studies were conducted in software engineering (SE) industry practice (evaluation research).Moreover, we analyzed the venue types concerning "validation" and "evaluation" research.Note that the grey literature shows 16.66% of studies with empirical evaluations even applied in the SE industry settings; this indicates that universities contribute to relevant academic studies in the GraphQL study (see Figure 27).In this sense, we discuss if it is possible to improve the maturity of empirical evidence of GraphQL studies.We ind that future research can improve this maturity if researchers use the methods described in Section 3.5 and apply them in the industry or government setting (i.e., SE practice).
In RQ4 (Section 4.4), we ind a growth of studies in quantity and quality.Figure 28 shows the relationship of the results of RQ2, RQ3, and RQ4; we observe that from 2019 appear works from journals that generally have more rigor for publication, as well as the quality of the empirical evidence exposed in "validation" and "evaluation" research.These results corroborate the motivation for conducting the present SMS.

Journals
Conferences Workshops Gray literature          In RQ5 (section 4.5), on the one hand, we irstly analyzed the study setting concerning the research type.We observed that most of the publications are of validation research type in academia (see Figure 27); this suggests that researchers did their studies in synthetic contexts without applying them in SE practice (i.e., industry or government).In this sense, we found that another key point to improve the quality of GraphQL research is to apply the studies in industry and government settings.On the other hand, we note that the publications conducted their study in 7 of the 15 SWEBOK knowledge areas (see Figure 22), opening a research opportunity in the rest of the knowledge areas described in Section 3.5.
In RQ6 (Section 4.6), we answer how the scientiic community studied the GraphQL paradigm through the following classiication metrics: technical contributions, their types and domains, GraphQL components, and public APIs used in publications.Figure 29 shows the relationship between RQ3 and RQ6.
First, Figure 23 shows that the researchers turned to study the domain provided by the GraphQL service (72.73%); we think this is normal behavior because the GraphQL service must irst be implemented before its  consumption; in this sense, we identify a study opportunity on usability, ease of learning, and consumption performance of the GraphQL service.Second, the studies' most frequent contribution types are implementation and GraphQL analysis (see Figure 29), published with similar frequency in conference papers and gray literature; in this sense, we note that implementations can improve their quality by validating or evaluating their studies using the research methods described in Section 3.5.Thirdly, in the "analysis" contribution type, the comparisons between REST and GraphQL are highlighted (see Table 12), clearly showing that the community studied GraphQL as an alternative to REST for implementing web APIs.Fourth, we mapped the components of the GraphQL paradigm that were mentioned, used, and exempliied in the publications.In a general way, we observed that the most studied components are queries, schemas, objects, and scalar types; we conclude that this behavior is because they are fundamental and necessary components to implement GraphQL APIs (see Figure 26).In this sense, we asked if there are components that should be studied more.This question surprised us because most components are not treated in detail, including essential components such as mutations and subscriptions, evidencing another gap in studies.Finally, we identiied that the GitHub public API is the most used in the publications, identifying a tendency to implement public REST APIs and support GraphQL APIs.
Finally, in RQ7 (section 4.7) we analyze the main indings of the publications and classify them to understand the frontiers in GraphQL research.Many studies highlight the advantages of GraphQL compared to REST (and SOAP) in features and quality metrics such as throughput, response size, dynamic query, and overload.We ind that the right conditions for using REST are when APIs perform static queries with little data; in contrast, GraphQL excels when performing dynamic queries with big datasets.As a possible roadmap for future work to overcome the limitations and challenges reported in GraphQL, we propose: i) Strengthen the baseline conditions for using REST and GraphQL to build eicient applications by increasing studies of experimental design complexity and data quantity scale (similar to those used in industrial environments).Also, adding diferent features such as quality characteristics (e.g., usability, functional adequacy), GraphQL operations (mutations and subscriptions), network conditions (e.g., bandwidth, concurrency), programming languages (backend, frontend), query languages (e.g., falcor, SPARQL), databases (relational and non-relational), and applied on various platforms such as mobile and IoT.
ii) Establish a baseline of existing best practices and encourage proposals for the management of caching, security in GraphQL APIs, and control of the inherent problems of GraphQL schemes and mutations reported in section 4.7.iii) Establish proposals that promote the governance of the software engineering process in developing GraphQL APIs and hybrid architectures between REST and GraphQL, such as code generation tools for advanced GraphQL components (e.g., pagination and nested queries), testing GraphQL APIs [32], or the management of GraphQL API service level agreements [35,39].iv) Non-Functional aspects such as limitations or pricing represent a key element for API practitioners [13,16] and are widely used in the RESTful API market [15];in contrast, this study shows a lack of approaches that address those concerns for GraphQL, which prevents the consolidation of an open market of GraphQL based services as it has been proposed in similar contexts [17,18,47].

CONCLUSIONS
GraphQL is a novel approach to APIs development that is gaining traction and interest from both researchers and practitioners.In order to ofer a global perspective on this ield, in this work we irst introduce a conceptual framework to describe the so-called GraphQL paradigm from its formal speciication, illustrating and exemplifying its components to serve as the basis to acquire a deep understanding of the GraphQL paradigm and relate the diferent elements studied.Then, as the main focus of our work, we conducted a systematic mapping study (SMS) of the literature to show an overview of the research and identify trends and gaps in the GraphQL ield.The SMS answered seven research questions and classiied the studies into general and speciic areas about GraphQL.
In particular, our study focused on inding out who, where, when, what, and why GraphQL was researched, as well as contextualizing the speciic areas of research with respect to the GraphQL paradigm we introduced.The results of our study conirm that in spite of its growing acceptance as an alternative for API development, there is not a widely established scientiic community around GraphQL.Even though there is a trend of publishing in high quality venues, there are still shortcomings in current studies, especially in terms of the maturity of empirical evidences, validation in realistic use cases, and the evaluation of additional quality characteristics and underused features of GraphQL.Furthermore, we also detected research opportunities in other areas related to best practices and proposals for the development and governance of GraphQL-based systems, including aspects like security, testing, and service level agreements, among others.In summary, even though the ield is young and needs to mature in some aspects, this study will help researchers get an overview of the topics investigated and directions for future GraphQL research.

Fig. 11 .Fig. 13 .
Fig. 11.Publication trend by year or book chapters VID = Videos, posters, or demonstrations NPREV = Non-peer-reviewed publications NENG = Non-English publications HOM = GraphQL publications (homonyms name) OREF = Publications that solely reference GraphQL AVA = Publications not available databasesstring in title TA = Search string in title and abstract EO = English only NC = Excluding citations or patents NA = Publications without authors name available d in p r a c t ic e N o v e l s o lu t io n E m p ir ic a l e v a lu a t io n C o n c e p t u a l f r a m e w o r k O p in io n a b o u t s o m e t h in g A u t h o r s ' e x p e r ie n c e Evaluation research T • T

Finding:
The study's indings; are usually in the results or conclusions study sections.Challenge: Challenges posed by the authors are usually in the discussion, conclusions, or future work sections of the study.Topic-speciic classiication scheme: The following describes the data extraction ields for the speciic classiication of the GraphQL paradigm: Knowledge area: software engineering knowledge areas based on the Guide to the Software Engineering Body of Knowledge SWEBOK version 3.0 of the IEEE Computer Society [3] are: Requirements, Design, Construction, Testing, Maintenance, Coniguration Management, Engineering Management, Engineering Process, Engineering Models and Methods, Quality, Engineering Professional Practice, Engineering Economics, Computing Foundations, Mathematical Foundations, and Engineering Foundations.Contribution domain: domain of the GraphQL service used in the study's technical contribution.We

Fig. 19 .
Fig. 19.Publications by research methods in validation and evaluation research types

%GT
Count of Nro by Year and Research type (RQ3)

Fig. 20 .
Fig. 20.Publications by research type and year

Fig. 21 .
Fig. 21.Publications by study seting and application domain

Fig. 24 .
Fig. 23.Publications by contribution domains promote studies of hybrid architectures between REST and GraphQL [S12, S13] to reuse existing REST APIs or as a transition from REST to GraphQL; analyze in-depth mutation and subscription operations, which have not yet been thoroughly studied [S03]; and analyze existing caching and security practices [S17] to realize the impact of their applicability, identify the best existing techniques or establish new proposals.As technical challenges related to the SE process, studies propose to build code generative tools for advanced elements such as paging or nested queries [S13], analyze how practitioners use GraphQL in real systems [S56], and analyze the impact of transitioning architectures such as REST or SOAP [S74], with the aim of improving the software development process.There are also additional challenges on the applicability of GraphQL in cutting-edge areas, such as devising a standardized approach and the semantics of GraphQL in the context of knowledge graphs [S06], or its application in IoT use cases [S14].

Fig. 27 .
Fig. 27.Publications by study seting, research type, and venue type

Fig. 28 .
Fig. 28.Publications by research type, year, and venue type

Table 1 .
[57,59nference ratingPublication types: for peer-reviewed types of venues are journal articles, conference papers, and workshop papers[42].For grey literature, according to the Finnish Ministry of Education thesis classiication16: Bachelor's, Master's, and Ph.D. theses Research type: we base it on the classiication of research types proposed by Wieringa[57]and complement it with the decision table to disambiguate the classiication of studies by checking a series of conditions proposed by Petersen et al.[42], see Table2.Next, we show and order the research types according to the maturity exposed by the studies[57,59]: Evaluation research, empirically evaluates the investigation of a problem or application of a technique in engineering practice.Validation research, develops a novel solution and is empirically evaluated in a laboratory setting (i.e., not used in practice).Solution proposal, this study proposes a solution to a research problem, and the beneits are discussed but not evaluated.Philosophical papers, structures an area in the form of taxonomy or conceptual framework, hence provides a new way of looking at existing things.Experience papers, includes the author's experience of what and how something happened in practice.

Table 2 .
Research type classification

Table 3 .
Data extraction structure Principal Author and Co-Author by Country

Table 4 .
Top authors by publications 0% Fig. 15.Authors by continent and country 4.2 RQ2: Where were the research papers published?

Table 6 .
Conference papers and their impact

Table 9 .
Publications by SE Knowledge areas

Table 10 .
Publications by contribution domains

Table 13 .
GraphQL advantages, disadvantages, and limitations identified in primary studies