Hartig and Perez (2017) define GraphQL as a new form of Web-based connectivity interface that provides alternatives to the concept of REST-based interfaces. Due to its benefits over REST, GraphQL has gained popularity since its debut. GraphQL has grown in popularity and is being used by many users. GraphQL is a novel technique of interacting using Web APIs. It is an open-source database querying and manipulation language for application programming interfaces (APIs). It is a dynamic, interactive query-based language for interacting with APIs (Eizinger, T. 2017; Hartig & Perez, 2017; Taelman et al., 2018). According to Hartig and Perez (2017), a client system that requires GraphQL might communicate with the servers precisely what they require; queries are built to connect with the web about what is necessary.
Brito et al. (2019) give a case study on migrating API customers to this new technology in this article. First, they surveyed the grey literature to acquire a thorough knowledge of the benefits and important qualities of GraphQL that practitioners typically connect with. Following that, Brito et al. demonstrate these benefits in reality by moving seven services to GraphQL rather than normal REST-based APIs. As a crucial finding, the researchers demonstrated that GraphQL could significantly reduce the volume of JSON documents supplied by REST APIs by 94 percent (in terms of fields) and 99 percent (in terms of bytes), both of which are median values (Brito et al., 2019). In his research blog, Kristopher Sandoval (2017) outlined the benefits of utilizing GraphQL. He also notes that since GraphQL is so strong, it has been employed by some service providers who require a high level of accessibility and indexing speed. For the most part, the useful applications for GraphQL are those that need fast data flow and easy sorting and representation by its most high-profile customers.
According to Vogel et al. (2017), GraphQL is not a database technology, as many people believe. Users may already be aware that most modern applications save their data on a distant server in a database, and here is where GraphQL comes in. Simply providing a means of accessing data required by the application is all required by the API. REST APIs may also be built with GraphQL (Vadlamani et al., 2021). It was created internally by Facebook for various purposes before being made open-source and made available to the public. Because of this, it has become one of the most used technology stacks for building online services. GraphQL is a query language that specifies how an application program can ask a distant server for the data it needs. Consequently, the requested client query receives a response from the server app. Client applications may inquire about what they need without relying on their server-side counterparts for guidance.
Olaf Hartig et al. (2019), in their research study, has focused on repurposing schemas for graph databases that are predicated on the Property Graph structure, which was initially intended as a language to describe a so-called GraphQL schema that clarifies various kinds of things, which can be queried when attempting to access a particular Web API. The researchers thus rearticulate the notion of Schema Definition Languages (SDL) from the perspective of data use -GraphQL uses a schema to express the form of the data graphs (Hartig et al., 2019). Many different viewpoints have been put together by Olaf Hartig et al. (2018) in his paper to define GraphQL schemas in terms of their quantitative definitions. GraphQL is sometimes described as an edge-labeled multi-graph with a dictionary of attributes, wherein every node is connected with an object type. Set F gives us the names of the fields in property keys. The three sets of fields (F), argument (A), and types (T)that make up a GraphQL schema; As stated by the authors, the graph (F, A, T) represents a tuple (Hartig et al., 2019).
An architectural model’s specific performance characteristics may be gleaned via studies on response time and average transfer rates between requests, as noted by Seabra et al. (2019). 2/3 of the evaluated applications found that moving to GraphQL led to a performance boost. After constructing REST and GRAPHQL API endpoints and testing them in an open-source playground, Seabra et al. performed a Proof of Concept not by transitioning to GRAPHQL but rather by establishing prototype API endpoints for both testings the response time for data extraction across three iterations.
Iteration 1: There was little or no change when we investigated a single API endpoint for GRAPHQL and REST with the 1000 data records quantity (Seabra et al., 2019). Iteration 2: 35% faster response time utilizing GRAPHQL, despite a tenfold increase in data volume than Iteration 1 and Iteration 2 were conducted with 10000 data records (Seabra et al., 2019). Iteration 3: Whenever Seabra et al. raise the quantity of data 100 times the initial quantity and run Iteration 3 using 100,000 data records, they evaluate three REST API endpoints rather than the needed one (Seabra et al., 2019). The researchers suggested a roughly 40 percent reduction in reaction time needed in the GRAPHQL experiment findings.
According to Seabra et al. among software development experts, the subject of which architectural model to adopt is frequently asked: This topic of performance has been answered by examining the performance of three different target apps, each of which was built utilizing two different web services architectural models: REST and GraphQL. Every architectural model’s performance indicators may be deduced from the study of reaction time and average transfer rates. Migration to GraphQL led to a dramatic increase in the average demand per second and information transfer rates in various evaluated apps. After the migration research, it was shown that GraphQL-based services performed worse than their REST-based counterparts for workloads exceeding 3000 requests, varying from 99 to 2160 KB per second. Both REST and GraphQL services performed similarly for simple workloads, with values ranging from 6.3 to 7.7 requests per second for work of 100 requests between GraphQL and REST services.
Researchers at Salt Security’s Salt Labs discovered the flaws in the FinTech firm’s mobile apps and SaaS platform while doing their study. Problems stemmed from a lack of authorization. Nested GraphQL queries are prone to such mistakes. Salt Labs discovered that the researchers might submit operations against any user’s account or capture any customer’s sensitive data if proper authorization checks were not implemented (Vadlamani et al., 2021). A report from Salt Security shows that 62 percent of firms have no or a minimal API security policy (Vadlamani et al., 2021). It can’t go on like this. A basic attack like not verifying or cleaning the API queries may lead to trouble.
According to Brito & Valente (2020), GRAPHQL is becoming increasingly popular as a preferable API management platform in environments with high data volumes, where response speed and the usage of fewer API endpoints are important performance indicators. Although REST is becoming an enterprise standard and API administration utilizing REST endpoints has evolved, GRAPHQL has a learning curve. With enhanced tooling features over time, future uses of GRAPHQL will rise manifold. This research spur other researchers to pursue performance, data-driven design, and flexibility in performance with minimal API involvement.
Several GraphQL implementations allow Introspection by default, which means they may be accessed without authentication (Eizinger, 2017). The fact that Introspection enables the requester to understand all of the available schema and queries is troublesome. API owners may use Introspection to inform users about the API’s workings and potential pitfalls. Users prefer to learn about a service via a distinct documentation channel like a Git Readme or reading the manuals. The safest and most convenient option is deactivating Introspection and the GraphiQL scheme (Eizinger, 2017). If disabling Introspection isn’t supported natively by the implementation, or if users want to provide this access to certain users or roles, therefore may create a filter in the service that restricts access to the introspection system to those users who have been allowed by the service’s administrators.
Even if Introspection is turned off, an attacker might still brute force fields to estimate their values. As a bonus, GraphQL comes with a built-in hinting function that asks, “Do you mean “user?” whenever a requester’s field title is close (but wrong) to an already-existing field. Not all installations of GraphQL enable this functionality; therefore, users should consider deactivating it if they want to reduce their exposure (Kourai & Juda, 2016). A tool like Shapeshifter might be able to help with this. Disabling Introspection is a sort of security via obscurity since bad actors still may learn ways to construct harmful queries by reverse-engineering the GraphQL API using several trials and errors (Kourai & Juda, 2016). It’s not the greatest protection method when used in conjunction with additional security measures such as volumetric quotas and operation safe listing. It is possible to examine all schema data using GraphQL Introspection.
When Introspection is enabled in production, it makes it easier for hostile actors to find graph weaknesses, such as disclosing sensitive information. Using a schema registry to record the graph and metadata is safer and more secure. SQL injection, OS Command Injection (SSRF/CRLF), NoSQL injection, and DoS attacks may all be prevented by disabling Introspection (Denial of Service) (Eizinger, T. 2017; Hartig & Perez, 2017; Taelman et al., 2018). Attacking the API’s accessibility and stability is a form of DoS, which can cause the API to be sluggish, unresponsive, or inaccessible (Gözneli, 2020; Kourai & Juda, 2016). An application-layer DoS attack can be mitigated by employing many of the techniques detailed in this CS. There’s a fair chance the target has Introspection turned off, so take advantage of this. GraphQL backends come pre-loaded with proposals for fields and functions. GraphQL may offer fields equivalent to the original query if users try to query the field but make a typo. Hackers can use the Field Suggestion functionality to learn more about GraphQL’s schema, even though it is not vulnerable (Gözneli, 2020).
An investigation on timeouts in GraphQL was conducted by Wittern et al. (2019). Adding timeouts is an easy approach to limit the number of resources a single request may use. The problem is that timeouts don’t always work since they don’t kick till a malicious query has used a large amount of computing power. There isn’t a single timeout number that will work for all APIs and data fetching mechanisms. If desired, queries and resolver functions can set timeouts at the application level. Because the timeout has been reached, this technique is typically more effective. Request timeouts cannot be implemented natively in GraphQL due to technical limitations. The proliferation of APIs has resulted in a rise in attempted assaults with automated apps executing harmful operations via the Application Programming Interfaces (Hartig & Perez, 2017). As per research from wallarm.com, harmful bots now account for up to 20 percent of the internet. As a result, protecting APIs is a vital component of application security.
GraphQL and REST API development lifecycle techniques are helpful in certain situations, and each has its own set of perks and downsides. GraphQL is growing in popularity at a breakneck pace, owing mostly to its “no over and under-fetching” capability (Hartig & Perez, 2017). It enables more effective client-side communication and is an extremely useful and powerful technology, particularly as the software sector transitions to an agile framework. GraphQL is a mechanism for accomplishing certain query-oriented goals; nevertheless, it is not a panacea for all API-related difficulties and is not a substitute for REST. When frontend development teams consume REST APIs, they must wait for the backend team to complete creating the APIs necessary for the client application to collect and send data.
The complete development process is entirely dependent on the creation and delivery of the REST API. The GraphQL lifecycle method is significantly different and more efficient, allowing frontend and backend programmers to operate concurrently without impeding the whole development process. GraphQL’s key quality is that it is less verbose than REST APIs. GraphQL prioritizes speed above everything else, whereas REST prioritizes service dependability. It doesn’t matter whether the REST API provides only a simple partial because it’s still sending more data than is necessary (Vadlamani et al., 2021). The API can add new fields to the GraphQL query, but clients don’t get them until they explicitly request them. REST is slower since users can’t select which fields to query; therefore, the request will be as minimal as possible, making it quicker with GraphQL.
Since GraphQL transfers fewer bits over the wire, the applications will run quicker than when using REST. Furthermore, developers may query several entities at once using GraphQL (Lawi et al. 2021). Unpredictable APIs are of no utility. As a result, every program that uses an API must be aware of what it may call and how it can anticipate; as a result, to act on the API’s output properly. In other words, an API’s explanation of what may be accessed is critical. GraphQL introspection and REST API schema frameworks such as Swagger allow developers to explore programmatically the information they gain from the API documentation.
Concerning security, REST appears to have the upper hand when comparing GraphQL to REST. API security may be enforced in several ways using REST (Vadlamani et al., 2021). For example, one may secure REST APIs by supporting several API authentication methods, such as the HTTP authentication mechanism. JSON Web Tokens, HTTP headers, or OAuth 2.0 protocols can all transmit private information, such as passwords and credit card numbers. In addition to REST, GraphQL has certain security features; however, they aren’t as developed as REST’s GraphQL (Lawi et al. 2021; Vadlamani et al., 2021). For example, it helps integrate data validation, but users must figure out how to implement permission and authentication procedures on top.
In their research, Vadlamani et al. (2021) investigated whether REST can replace GraphQL. In API development, REST has long been the go-to architectural approach. In 2015, Facebook announced GraphQL, which has since challenged GraphQL’s popularity. GitHub, Airbnb, Shopify, Twitter, and many other internet platforms have already implemented it (Vadlamani et al., 2021). Many questions remain unanswered about the efficiency and viability of GraphQL’s application, even if it offers a significant improvement over REST. This article aims to evaluate the quantity and quality viability of adopting GraphQL over REST for API design. When it comes to API response speeds, GitHub has built a unique API client that can be used to measure the change between REST and GraphQL. After that, a poll of GitHub workers was conducted to better understand what REST and GraphQL mean in software engineers’ experience with APIs. Both API paradigms have advantages and disadvantages, and none can substitute the other.
There is a clear preference in the GraphQL versus REST argument for REST APIs. A State of API 2020 report found that 82% of API customers and practitioners utilize REST-based OpenAPI authentication, whereas just 18% use GraphQL (Vadlamani et al., 2021). There has also been a steady rise in GraphQL’s popularity. JavaScript use has increased from 5 percent in 2016 to 38 percent in 2019, as per the State of JavaScript 2019 Report (Vadlamani et al., 2021). Today, most browsers support the HTTP cache so that resources aren’t re-fetched. It can also be used to tell if two factors are identical in any other way. In GraphQL, users can’t use the same URL for all requests to receive a globally unique id for an item. For this, one will need to configure the GraphQL cache.
References
Brito, G., & Valente, M. T. (2020, March). REST vs. GraphQL: A controlled experiment. In 2020 IEEE international conference on software architecture (ICSA) (pp. 81-91). IEEE.
Brito, G., Mombach, T., & Valente, M. T. (2019, February). Migrating to GraphQL: A practical assessment. In 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) (pp. 140-150). IEEE.
Eizinger, T. (2017). API design in distributed systems: a comparison between GraphQL and REST. University of Applied Sciences Technikum Wien-Degree Program Software Engineering.
Gözneli, B. (2020). Identification and Evaluation of a Process for Transitioning from REST APIs to GraphQL APIs in the Context of Microservices Architecture (Doctoral dissertation, Technische Universität München).
Hartig, O., & Hidders, J. (2019, June). I am defining schemas for property graphs using the GraphQL schema definition language. In Proceedings of the 2nd Joint International Workshop on Graph Data Management Experiences & Systems (GRADES) and Network Data Analytics (NDA) (pp. 1-11).
Hartig, O., & Pérez, J. (2017). An initial analysis of Facebook’s GraphQL language. In AMW 2017 11th Alberto Mendelzon International Workshop on Foundations of Data Management and the Web, Montevideo, Uruguay, June 7-9, 2017. (Vol. 1912). Juan Reutter, Divesh Srivastava.
Kourai, K., & Juda, K. (2016, June). Secure offloading of legacy IDSes using remote VM introspection in semi-trusted clouds. In 2016 IEEE 9th International Conference on Cloud Computing (CLOUD) (pp. 43-50). IEEE.
Lawi, A., Panggabean, B. L., & Yoshida, T. (2021). Evaluating GraphQL and REST API Services Performance in a Massive and Intensive Accessible Information System. Computers, 10(11), 138.
Seabra, M., Nazário, M. F., & Pinto, G. (2019, September). Rest or graphql? A comparative performance study. In Proceedings of the XIII Brazilian Symposium on Software Components, Architectures, and Reuse (pp. 123-132).
Taelman, R., Vander Sande, M., & Verborgh, R. (2018). GraphQL-LD: linked data querying with GraphQL. In ISWC2018, the 17th International Semantic Web Conference (pp. 1-4).
Vadlamani, S. L., Emdon, B., Arts, J., & Baysal, O. (2021, June). 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) (pp. 10-17). IEEE.
Vogel, M., Weber, S., & Zirpins, C. (2017, November). Experiences in migrating RESTful web services to GraphQL. In International Conference on Service-Oriented Computing (pp. 283-295). Springer, Cham.
Wittern, E., Cha, A., Davis, J. C., Baudart, G., & Mandel, L. (2019, October). An empirical study of GraphQL schemas. In International Conference on Service-Oriented Computing (pp. 3-19). Springer, Cham.
write