Technical ReportPDF Available

A Link Generator for Increasing the Utility of OpenAPI-to-GraphQL Translations

Authors:

Abstract and Figures

Standardized interfaces are the connecting link of today's distributed systems, facilitating access to data services in the cloud. REST APIs have been prevalent over the last years, despite several issues like over- and underfetching of resources. GraphQL enjoys rapid adoption, resolving these problems by using statically typed queries. However, the redevelopment of services to the new paradigm is costly. Therefore, several approaches for the successive migration from REST to GraphQL have been proposed, many leveraging OpenAPI service descriptions. In this article, we present the findings of our empirical evaluation on the APIs.guru directory and identify several schema translation challenges. These include less expressive schema types in GraphQL, as well as missing meta information about related resources in OpenAPI. To this end, we developed the open source Link Generator, that analyzes OpenAPI documents and automatically adds links to increase translation utility. This fundamentally benefits around 34% of APIs in the APIs.guru directory. Our findings and tool support contribute to the ongoing discussion about the migration of REST APIs to GraphQL, and provide developers with valuable insights into common pitfalls, to reduce friction during API transformation.
Content may be subject to copyright.
A Link Generator for Increasing the Utility of
OpenAPI-to-GraphQL Translations
Dominik Adam Kus, István Koren, Ralf Klamma
RWTH Aachen University
Aachen, Germany
kus,koren,klamma@dbis.rwth-aachen.de
ABSTRACT
Standardized interfaces are the connecting link of today’s distributed
systems, facilitating access to data services in the cloud. REST APIs
have been prevalent over the last years, despite several issues like
over- and underfetching of resources. GraphQL enjoys rapid adop-
tion, resolving these problems by using statically typed queries.
However, the redevelopment of services to the new paradigm is
costly. Therefore, several approaches for the successive migration
from REST to GraphQL have been proposed, many leveraging Ope-
nAPI service descriptions. In this article, we present the ndings of
our empirical evaluation on the APIs.guru directory and identify
several schema translation challenges. These include less expressive
schema types in GraphQL, as well as missing meta information
about related resources in OpenAPI. To this end, we developed the
open source Link Generator, that analyzes OpenAPI documents and
automatically adds links to increase translation utility. This funda-
mentally benets around 34% of APIs in the APIs.guru directory.
Our ndings and tool support contribute to the ongoing discus-
sion about the migration of REST APIs to GraphQL, and provide
developers with valuable insights into common pitfalls, to reduce
friction during API transformation.
KEYWORDS
Web APIs, GraphQL, OpenAPI, REST
1 INTRODUCTION
The modern web is powered by APIs. They enable all kinds of
distributed applications, like web and mobile apps connecting to
microservice architectures. Prominent examples are cloud-oriented
data processing frameworks running on the AWS Cloud or the
Google Cloud Platform, and the orchestration of container appli-
cations with Kubernetes. Since its proposal in the year 2000, the
REST API style [
5
] has become the most used interface type on
the web. However, there are some shortcomings of REST-based
interfaces. In particular, over- and underfetching are common prob-
lems when designing such an interface [
10
]. Overfetching occurs
when a client needs a specic piece of information but that informa-
tion is only available from the API in conjunction with additional
data. The client has to fetch more data than it actually needs. The
opposite is true for underfetching: the client has to perform mul-
tiple requests against the interface to fetch all the information it
This paper is published under the Creative Commons Attribution 4.0 International
(CC-BY 4.0) license. Authors reserve their rights to disseminate the work on their
personal and corporate Web sites with the appropriate attribution.
WWW ’20, April 20–24, 2020, Taipei, Taiwan
©2020 published under Creative Commons CC-BY 4.0 License.
requires. This can lead to increased bandwidth usage and higher
latency for the client, limiting the applications’s performance and
degrading the user experience. Additionally, complex queries are
particularly detrimental for data science in the context of high vol-
ume Internet of Things data, for instance in Industry 4.0 settings.
To tackle the shortcomings of REST, many new API-related tech-
nologies are currently being discussed. One of those technologies
is the modern web API style GraphQL. After its release in 2015, it
quickly gained popularity among developers and is used for many
public APIs as of today. Among others, GitHub and Facebook are
using GraphQL to provide their services. One reason for GraphQL’s
quick success is its promise to solve the above mentioned issues
encountered when using REST APIs. This is enabled by its query
language which allows developers to write statically typed queries,
thereby enabling clients to fetch complex data in a single request
while also providing a high degree of granularity. Together with
being very developer-friendly, those properties make GraphQL
highly interesting to providers of web services, in particular with
mobile frontends. As it can be very time consuming to migrate
an existing REST interface to GraphQL or to maintain interfaces
of both styles at the same time, there is a need for tools that can
aid this transition. One of those tools is the open-source project
OpenAPI-to-GraphQL
1
introduced by Wittern et al. [
9
]. It automat-
ically generates GraphQL wrappers and a corresponding schema
for existing REST APIs, based on their OpenAPI documentation.
Such a wrapper translates incoming GraphQL requests to the corre-
sponding REST calls, issues those calls and assembles the responses
into a valid GraphQL response. Thereby, it acts as a middleman
between the GraphQL client and the existing REST interface. As
a result, a wrapper works on top of an existing interface and does
not required changes of the underlying application.
In this article, we discuss challenges that arise when creating a
GraphQL wrapper, in particular using OpenAPI-to-GraphQL. As
the quality of the generated wrapper heavily depends on the source
documentation, we statistically evaluate real-world API documen-
tations in the public APIs.guru directory regarding their suitability
for wrapper generation. Finally, we introduce our link generator
tool that aims to those documentations and therefore improve the
wrapper generation process.
The article is organized as follows. In the next section, we in-
troduce related work in the area of API migration. Section 3 then
discusses schema translation challenges found in an empirical study.
Section 4 presents the implementation of the Link Generator. Fi-
nally, Section 5 wraps up the article.
1https://github.com/IBM/openapi-to- graphql
arXiv:2005.08708v1 [cs.DC] 18 May 2020
WWW ’20, April 20–24, 2020, Taipei, Taiwan Developers Track
2 RELATED WORK
Regarding the benets GraphQL oers over REST, a case study
conducted in [
1
] found a 99% reduction in the size of a query result
in the median when switching to GraphQL. Aside from performance,
the example in [
4
] shows that GraphQL also has the potential to
provide an outward data model that is similar to the internally
used data model. Furthermore, it enables uid API development
without the need for explicit versioning while still maintaining
compatibility.
The concept of GraphQL wrappers as well as an implementation
example on the client side is presented in [
6
]. However, the wrap-
per is manually implemented in this example. A tool for automatic
wrapper generation is Swagger2GraphQL
2
. It takes the Swagger
2.0 documentation of a REST interface as inputs and wraps the
API automatically. The tool OpenAPI-to-GraphQL which was intro-
duces by Wittern et al. [
9
] works in a similar fashion but uses the
more recent OpenAPI 3.0 format as input. Therefore, it can leverage
new features of the most recent OpenAPI version to enhance the
generated GraphQL schema. One of those is the link denition
feature discussed in this article.
3 SCHEMA TRANSLATION CHALLENGES
The rst step to generate such a wrapper is translating the schema
of the REST API into a GraphQL schema. The schema determines
the data model of the generated interface and therefore impacts
the developer friendliness and usability of it. However, the quality
of the generated schema depends heavily on the source OpenAPI
documentation. To assess the inuence of the source documentation
on the generated wrapper, we performed an empirical evaluation of
over 1500 of such documents found in the APIs.guru
3
directory. In
our analysis, we derived several translation challenges, particularly
when using OpenAPI-to-GraphQL4.
First, OpenAPI can model multiple dierent response types based
on a HTTP success status code (200–299). This has no direct equiv-
alent in GraphQL. In such a case, OpenAPI-to-GraphQL displays
a warning and translates only the numerically smallest dened
status code, ignoring the others. As a consequence, the generated
wrapper may be missing some of the functionality of the original
interface. Around 26% of APIs contain an at least one endpoint
aected by this limitation. Second, we compared the expression
of data format descriptions in OpenAPI and GraphQL and found
several specic properties in OpenAPI that cannot be expressed in
a GraphQL schema, like patterns. OpenAPI schema denitions are
based on the JSON Schema specication which allows narrowing
down allowed values for data types [
8
]. For example, they allow to
dene that a string has to be of a certain form using a pattern. The
GraphQL schema language, however, does not contain an equiva-
lent mechanism. In total, we found that there are 16 such OpenAPI
schema object properties with no direct GraphQL equivalent. Thus,
creating a wrapper for APIs using those properties will inevitably
result in a loss of schema information. An overview of those prop-
erties together with their prevalence in documentations found in
the APIs.guru directory can be found in Table 1. While some of
2https://github.com/yarax/swagger-to- graphql
3https://github.com/APIs-guru/openapi- directory
4OpenAPI-to-GraphQL version 2.0 was used during testing.
those properties, namely oneOf,anyOf and not, are already being
handled by OpenAPI-to-GraphQL at the time of writing, translating
the others to GraphQL remains an open challenge. In total, about
33% of the documents include at least one of those properties.
Third, missing link denitions in OpenAPI are a major pain point.
They allow dening inter-relationships between various resources,
which are reected in the translated GraphQL schema. As a result,
the added elds increase the readability and intuitiveness of the
schema. In some cases, especially when fetching a list of objects, it
can even increase the amount of data that can be fetched in a single
server roundtrip. An example for the improvement achieved by
adding link denitions is shown in Figure 1 using GitHub’s v3 API.
It shows a query that fetches a repository and its list of branches
from the wrapper generated by OpenAPI-to-GraphQL with and
without using the link generator. When links are added, a reposi-
tory and its list of branches are no longer unrelated in the GraphQL
API. As a result, querying them is no longer done through two
distinct top-level elds. Instead, the branches become a property
of their repository. This is much more intuitive as conceptually,
the branches are specic for the repository which is now reected
in the API schema. Furthermore, it is no longer necessary for the
client to specify the same parameters
owner
and
repo
twice in the
query. This is more concise and also eliminates a potential source
of errors. The example shows that adding links to an OpenAPI
document can signicantly improve the quality of the wrapper
generated by OpenAPI-to-GraphQL. However, despite their high
importance for the translation to GraphQL, we could only nd link
denitions in 3 out of the over 1500 documents in the APIs.guru
directory. We see one reason for that in the current low adoption
rate of OpenAPI 3.0. As link denitions were rst introduced with
version 3 of the OpenAPI specication, documents using previous
versions are inevitably missing link denitions. To combat their low
prevalence, we created OpenAPI-Link-Generator to greatly improve
generated GraphQL wrappers. It automatically adds link denitions
to OpenAPI documents whenever possible based on several heuris-
tics. In the process, it converts OpenAPI documents to version 3, if
necessary.
4 OPENAPI-LINK-GENERATOR
OpenAPI-Link-Generator was created to improve the quality of
the transition to GraphQL. To do that, it enables users to leverage
the existing support for link denitions in OpenAPI-to-GraphQL
without the need to manually go through the tedious process of
adding links to existing API documentation. As such, it can be used
in a pre-processing step before applying OpenAPI-to-GraphQL
to improve the translation result. It is developed as open source
software within our GitHub organization
5
. The link generator is
available as a freely accessible web service
6
and as a Node.js library
distributed through npm
7
which also includes a command line tool.
Figure 2 shows a screenshot of the web application. It provides
three input possibilities. First, the raw text can be pasted in. Second,
an OpenAPI le can be chosen from the local le system. Third,
a URL can be pasted it that links to a specication le. After the
5https://github.com/rwth-acis/openapi- link-generator
6https://openapi-link- generator.herokuapp.com
7https://www.npmjs.com/package/openapi-link- generator
A Link Generator for Increasing the Utility of OpenAPI-to-GraphQL Translations WWW ’20, April 20–24, 2020, Taipei, Taiwan
Property Documents Meaning
Count Ratio
multipleOf 1 0.1% Enforces that a number is a multiple of a given number.
minimum 287 18.3% Enforces that a number is within a given range.
maximum 241 15.3%
exclusiveMinimum 1 0.1% Species whether the range is including or excluding the given minimum or maximum respectively.
exclusiveMaximum 1 0.1%
minLength 326 20.8% Enforces that a string has a length within a given range.
maxLength 327 20.8%
pattern 329 20.9% Enforces that a string matches a given pattern.
minItems 110 7.0% Enforces that an array must have a number of items within a given range.
maxItems 111 7.1%
uniqueItems 12 0.8% Enforces that an array contains no duplicate items.
minProperties 29 1.8% Enforces that an object must have a number of properties within a given range.
maxProperties 39 2.5%
oneOf 7 0.4% Requires an object to adhere to exactly one or at least one schema within an array of schemas respectively.
anyOf 2 0.1%
not 0 0.0% Enforces that given data must not adhere to a given schema.
Table 1: OpenAPI schema object properties with no direct equivalent in GraphQL and their prevalence on APIs.guru.
(a) Without link generator
1{
2re po s ( o wn e r : "o", re p o : "r") {
3name
4}
5re p os B ra n c he s ( o wn e r : "o", re p o : "r") {
6name
7}
8}
(b) With link generator
1{
2re po s ( o wn e r : "o", re p o : "r") {
3name
4branches {
5name
6}
7}
8}
Figure 1: Querying a repository and its branches from the GraphQL wrapper generated by running OpenAPI-to-GraphQL on
the GitHub API with and without using the link generator.
link generation process, we show the di and some statistics on the
number of generated links.
It is noteworthy that we currently only consider HTTP GET
requests for adding links. For simplicity, we therefore use OpenAPI
paths and the GET operation dened on that path synonymously in
the following. As there is no universal rule where a link should be
added to an OpenAPI document and where not, the link generator
has to rely on heuristics to add links. The most important heuristic is
the assumption that the forward slash in a URI implies a hierarchical
relationship. This is a general rule of REST API design according
to Massé
[7]
and should therefore hold for most APIs. Based on
this assumption, the link generator tries to add links for each pair
of paths of the form
/A
and
/A/B
where
A
and
B
may be arbitrary
URI parts. After such a path pair is identied, it is necessary to
compare the parameters dened for those two paths. Here, another
heuristic is used. If both operations contain a parameter with the
same name as well as an identical schema, we assume that those two
parameters have the same semantic meaning. In this case, the link
generator adds a parameter mapping for those two parameters to
the generated link. This is required to prevent the user from having
to redene the same parameters multiple times when fetching
nested data. Note that for this functionality, the link generator also
parses internal references in the OpenAPI document according to
the specication [2, 3, 8].
To evaluate the link generator, we ran it on the OpenAPI docu-
mentations found in the APIs.guru dataset. In total, it added over
7500 link denitions, aecting about 34% of the documents. One
prominent example for the improvement achieved by the link gen-
erator is shown in Figure 1 and is discussed in Section 3. We are
convinced that our tool is a valuable addition to the growing ecosys-
tem of web API tooling, enabling a more sustainable translation
from OpenAPI to GraphQL.
5 CONCLUSION
GraphQL is one of the most promising new API styles, rapidly
gaining popularity and market share. It provides benets for de-
velopers and providers alike and consequentially is appealing to
WWW ’20, April 20–24, 2020, Taipei, Taiwan Developers Track
Figure 2: Screenshot of the OpenAPI-Link-Generator web service.
many providers of REST APIs. The open-source tool OpenAPI-to-
GraphQL can be used to automatically generate a GraphQL API
from an existing REST interface by creating a wrapper based on
its OpenAPI documentation. However, missing link denitions in
OpenAPI documents limit the quality of the generated wrapper.
To tackle this problem, we proposed the OpenAPI-Link-Generator
tool. It can be used to automatically add link denitions to existing
OpenAPI documentations and thereby improve the outcome of a
GraphQL migration. The tool is available through npm
8
as a nodejs
module and as a command line tool. Furthermore, we provide a
web-based tool
9
that can apply the link generator to any OpenAPI
document at the click of a button.
ACKNOWLEDGMENTS
Funded by the Deutsche Forschungsgemeinschaft (DFG, German
Research Foundation) under Germany’s Excellence Strategy – EXC-
2023 Internet of Production – 390621612.
REFERENCES
[1]
Gleison Brito, Thais Mombach, and Marco Tulio Valente. 24.02.2019 - 27.02.2019.
Migrating to GraphQL: A Practical Assessment. In 2019 IEEE 26th International
Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE,
140–150. https://doi.org/10.1109/SANER.2019.8667986
[2]
Paul C. Bryan and Kris Zyp. 2012. JSON Pointer: draft-ietf-appsawg-json-pointer-
04. https://tools.ietf.org/html/draft-ietf- appsawg-json- pointer-04
[3]
Paul C. Bryan and Kris Zyp. 2012. JSON Reference: draft-pbryan-zyp-json-ref-03.
https://tools.ietf.org/html/draft-pbryan- zyp-json- ref-03
[4]
Mike Bryant. 12/11/2017 - 12/14/2017. GraphQL for archival metadata: An
overview of the EHRI GraphQL API. In 2017 IEEE International Conference on Big
Data (Big Data). IEEE, 2225–2230. https://doi.org/10.1109/BigData.2017.8258173
[5]
Roy T.Fielding. 2000. ArchitecturalStyles and the Design of Network-based Software
Architectures. Doctoral Dissertation. University of California, Irvine, Irvine, CA,
USA. http://www.ics.uci.edu/~elding/pubs/dissertation/top.htm
8https://www.npmjs.com/package/openapi-link- generator
9https://openapi-link- generator.herokuapp.com
[6]
Steven Luscher. 2016. Wrapping a REST API in GraphQL. https://graphql.org/
blog/rest-api- graphql-wrapper/
[7] Mark Massé. 2012. REST API design rulebook. O’Reilly, Farnham.
[8]
OpenAPI Initiative. 2018. The OpenAPI Specication: Version 3.0.2. https:
//www.openapis.org
[9]
Erik Wittern, Alan Cha, and Jim A. Laredo. 2018. Generating GraphQL-Wrappers
for REST(-like) APIs. In Web Engineering (Lecture Notes in Computer Science),
Tommi Mikkonen, Ralf Klamma, and Juan Hernández (Eds.), Vol. 10845. Springer
International Publishing, Cham, 65–83. https://doi.org/10.1007/978-3- 319-91662-
0_5
[10]
Uwe Zdun, Erik Wittern, and Philipp Leitner. 2020. Emerging Trends, Challenges,
and Experiences in DevOps and Microservice APIs. IEEE Softw 37, 1 (2020), 87–91.
https://doi.org/10.1109/MS.2019.2947982
Chapter
Full-text available
We explain what properties the jury looked for to identify strong contributions and why they are important. They are formulated as seven pieces of advice: (1) Be in scope, (2) Enumerate your assumptions, (3) Delineate your contribution, (4) Honestly discuss limitations, (5) Show usefulness and practical applicability, (6) Have a well-prepared nutshell, and (7) Be timeless.
Chapter
Full-text available
Differential software testing is important for software quality assurance as it aims to automatically generate test inputs that reveal behavioral differences in software. Detecting regression bugs in software evolution, analyzing side-channels in programs, maximizing the execution cost of a program over multiple executions, and evaluating the robustness of neural networks are instances of differential software analysis to generate diverging executions of program paths. The key challenge thereby is to simultaneously reason about multiple program paths, often across program variants, in an efficient way. Existing work in differential testing is often not (specifically) directed to reveal a different behavior or is limited to a subset of the search space. This work proposes the concept of Hybrid Differential Software Testing ( HyDiff ) as a hybrid analysis technique to generate difference revealing inputs. HyDiff consists of two components that operate in a parallel setup: (1) a search-based technique that inexpensively generates inputs and (2) a systematic exploration technique to also exercise deeper program behaviors. HyDiff ’s search-based component uses differential fuzzing directed by differential heuristics. HyDiff ’s systematic exploration component is based on differential dynamic symbolic execution that allows to incorporate concrete inputs in its analysis. HyDiff is evaluated experimentally with applications specific for differential testing. The results show that HyDiff is effective in all considered categories and outperforms its components in isolation.
Chapter
Full-text available
Modern software architectures are becoming increasingly complex and interdependent. The days of exclusive in-house software development by companies are over. A key force contributing to this shift is the abundant use of open source frameworks, components, and libraries in software development. Over 90% of all software products include open source components. Being efficient, robust, and affordable, they often cover the non-differentiating product requirements companies have. However, the uncontrolled use of open source software in products comes with legal, engineering, and business risks stemming from incorrect software licensing, copyright issues, and supply chain vulnerabilities. While recognized by a handful of companies, this topic remains largely ignored by the industry and little studied by the academia. To address this relevant and novel topic, we undertook a 3-year research project into open source governance in companies, which resulted in a doctoral dissertation. The key results of our work include a theory of industry best practices, where we captured how more than 20 experts from 15 companies worldwide govern their corporate use of open source software. Acknowledging the broad industry relevance of our topic, we developed a handbook for open source governance that enabled practitioners from various domains to apply our findings in their companies. We conducted three evaluation case studies, where more than 40 employees at three Germany-based multinational companies applied our proposed best practices. This chapter presents the highlights of building and implementing the open source governance handbook.
Chapter
Full-text available
Modern embedded software systems are becoming more and more complex. Engineering embedded systems raise specific challenges that are rarely present in other software engineering disciplines due to the systems’ steady interactions with their environment. Research and industry often describe embedded systems as component and connector models (C&C). C&C models describe the logical architecture by focusing on software features and their logical communications. In C&C models, hierarchical decomposed components encapsulate features, and connectors model the data flow between components via typed ports. As extra-functional properties, for example, safety and security, are also key features of embedded systems, C&C models are mostly enriched with them. However, the process to develop, understand, validate, and maintain large C&C models for complex embedded software is onerous, time consuming, and cost intensive. Hence, the aim of this chapter is to support the automotive software engineer with: (i) automatic consistency checks of large C&C models, (ii) automatic verification of C&C models against design decisions, (iii) tracing and navigating between design and implementation models, (iv) finding structural inconsistencies during model evolution, (v) presenting a flexible approach to define different extra-functional properties for C&C models, and (vi) providing a framework to formalize constraints on C&C models for extra-functional properties for automatic consistency checks.
Chapter
Full-text available
This is the introductory chapter of the book on the Ernst Denert Software Engineering Award 2020. It provides an overview of the 11 nominated PhD theses, the work of the award winner, and the structure of the book.
Chapter
Full-text available
Legacy systems are business-critical software systems whose failure can have a significant impact on the business. Yet, their maintenance and adaption to changed requirements consume a considerable amount of the total software development costs. Frequently, domain experts and developers involved in the original development are not available anymore, making it difficult to adapt a legacy system without introducing bugs or unwanted behavior. This results in a dilemma: businesses are reluctant to change a working system, while at the same time struggling with its high maintenance costs. We propose the concept of Structured Software Reengineering replacing the ad hoc forward engineering part of a reengineering process with the application of behavior-preserving, proven-correct transformations improving nonfunctional program properties. Such transformations preserve valuable business logic while improving properties such as maintainability, performance, or portability to new platforms. Manually encoding and proving such transformations for industrial programming languages, for example, in interactive proof assistants, is a major challenge requiring deep expert knowledge. Existing frameworks for automatically proving transformation rules have limited expressiveness and are restricted to particular target applications such as compilation or peep-hole optimizations. We present Abstract Execution , a specification and verification framework for statement-based program transformation rules on JAVA programs building on symbolic execution. Abstract Execution supports universal quantification over statements or expressions and addresses properties about the (big-step) behavior of programs. Since this class of properties is useful for a plethora of applications, Abstract Execution bridges the gap between expressiveness and automation. In many cases, fully automatic proofs are in possible. We explain REFINITY, a workbench for modeling and proving statement-level JAVA transformation rules, and discuss our applications of Abstract Execution to code refactoring, cost analysis of program transformations, and transformations reshaping programs for the application of parallel design patterns.
Chapter
Full-text available
Recent advances in mobile connectivity as well as increased computational power and storage in sensor devices have given rise to a new family of software architectures with challenges for data and communication paths as well as architectural reconfigurability at runtime. Established in 2012, Fog Computing describes one of these software architectures. It lacks a commonly accepted definition, which manifests itself in the missing support for mobile applications as well as dynamically changing runtime configurations. The dissertation “Dynamically Scalable Fog Architectures” provides a framework that formalizes Fog Computing and adds support for dynamic and scalable Fog Architectures. The framework called xFog (E x tension for Fog Computing) models Fog Architectures based on set theory and graphs. It consists of three parts: xFogCore, xFogPlus, and xFogStar. xFogCore establishes the set theoretical foundations. xFogPlus enables dynamic and scalable Fog Architectures to dynamically add new components or layers. Additionally, xFogPlus provides a View concept which allows stakeholders to focus on different levels of abstraction. These formalizations establish the foundation for new concepts in the area of Fog Computing. One such concept, xFogStar, provides a workflow to find the best service configuration based on quality of service parameters. The xFog framework has been applied in eight case studies to investigate the applicability of dynamic Fog Components, scalable Fog Architectures, and the service provider selection at runtime. The case studies, covering different application domains—ranging from smart environments, health, and metrology to gaming—successfully demonstrated the feasibility of the formalizations provided by xFog, the dynamic change of Fog Architectures by adding new components and layers at runtime, as well as the applicability of a workflow to establish the best service configuration.
Chapter
Full-text available
Debugging is one of the most expensive and challenging phases in the software development life-cycle. One important cost factor in the debugging process is the time required to analyze failures and find underlying faults. Two types of techniques that can help developers to reduce this analysis time are Failure Clustering and Automated Fault Localization. Although there is a plethora of these techniques in the literature, there are still some gaps that prevent their operationalization in real-world contexts. Besides, the abundance of these techniques confuses the developers in selecting a suitable method for their specific domain. In order to help developers in reducing analysis time, we propose methodologies and techniques that can be used standalone or in a form of a tool-chain. Utilizing this tool-chain, developers (1) know which data they need for further analysis, (2) are able to group failures based on their root causes, and (3) are able to find more information about the root causes of each failing group. Our tool-chain was initially developed based on state-of-the-art failure diagnosis techniques. We implemented and evaluated existing techniques. We built on and improved them where the results were promising and proposed new solutions where needed. The overarching goal of this study has been the applicability of techniques in practice.
Chapter
Full-text available
Software requirements specifications (SRS) serve as an important source of information for a variety of roles involved in software engineering (SE) projects. This situation poses a challenge to requirements engineers: Different information needs have to be addressed, which are strongly dependent on the particular role(s) that SRS stakeholders have within a project. This chapter summarizes the contributions of a thesis that aimed to address and reduce role-specific defects in SRS that negatively influence the efficient usage and acceptance of these documents. To achieve this goal, we collected empirical data about role-specific information needs in a series of empirical studies that served as a baseline for a secondary analysis toward the definition of role-specific views. Moreover, we realized a proof-of-concept implementation that is capable of generating role-specific views on SRS. The results of a case study revealed that role-specific views have the potential to efficiently support SRS consumers during the analysis of a given SRS. Besides conducting further empirical studies in industry, future work aims to foster cross-disciplinary collaboration and requirements communication, especially in agile teams. Thereby, we are exploring synergy potential with best practices from non-SE disciplines.
Chapter
Full-text available
Structuring control flow is an essential task almost every programmer faces on a daily basis. At the same time, the control flow of software applications is becoming increasingly complicated, motivating languages to include more and more features like asynchronous programming and generators. Effect handlers are a promising alternative since they can express many of these features as libraries. To bring effect handlers closer to the software engineering practice, we present capability passing as an implementation technique for effect handlers. Capability passing provides the basis for the integration of effect handlers into mainstream object-oriented programming languages and thereby unlocks novel modularization strategies. It also enables programmers to apply lexical reasoning about effects and gives rise to a new form of effect polymorphism. Finally, it paves the path for efficient compilation strategies of control effects.
Conference Paper
Full-text available
GraphQL is a novel query language proposed by Facebook to implement Web-based APIs. In this paper, we present a practical study on migrating API clients to this new technology. First, we conduct a grey literature review to gain an in-depth understanding on the benefits and key characteristics normally associated to GraphQL by practitioners. After that, we assess such benefits in practice, by migrating seven systems to use GraphQL, instead of standard REST-based APIs. As our key result, we show that GraphQL can reduce the size of the JSON documents returned by REST APIs in 94% (in number of fields) and in 99% (in number of bytes), both median results.
Article
In August 2019, we organized the second Vienna Software Seminar (VSS) with the topic "DevOps and Microservice APIs."1 Embracing the positive reception of its first iteration in 2017,2 VSS is an opportunity for attendees to discuss recent software technologies, practices, and related research. The seminar's 34 participants included a mix of practitioners and academics, who were invited based on their roles and experiences. The explicit intention of the seminar was to provide ample opportunities for exchange and communication: six themed sessions consisted of one invited keynote and two lightning talks, giving different perspectives on the session?s topic and (ideally) sparking ideas for follow-up discussions. After the talks, all participants decided on subtopics for two to three breakout sessions (i.e., informal, self-organized discussions among interested participants). Breakout session topics included microservice security, tooling for application programming interface (API) evolution, serverless programming models, and identification of microservices using domaindriven design. The sessions provided opportunities for detailed discussions and identifying challenges to address in future collaborations. Toward the end of each session, all participants gathered once more to summarize the breakout discussions. Additional opportunities for communication were provided during shared lunch breaks and social events in the evenings.
Chapter
GraphQL is a query language and thereupon-based paradigm for implementing web Application Programming Interfaces (APIs) for client-server interactions. Using GraphQL, clients define precise, nested data-requirements in typed queries, which are resolved by servers against (possibly multiple) backend systems, like databases, object storages, or other APIs. Clients receive only the data they care about, in a single request. However, providers of existing REST(-like) APIs need to implement additional GraphQL interfaces to enable these advantages. We here assess the feasibility of automatically generating GraphQL wrappers for existing REST(-like) APIs. A wrapper, upon receiving GraphQL queries, translates them to requests against the target API. We discuss the challenges for creating such wrappers, including dealing with data sanitation, authentication, or handling nested queries. We furthermore present a prototypical implementation of OASGraph. OASGraph takes as input an OpenAPI Specification (OAS) describing an existing REST(-like) web API and generates a GraphQL wrapper for it. We evaluate OASGraph by running it, as well as an existing open source alternative, against 959 publicly available OAS. This experiment shows that OASGraph outperforms the existing alternative and is able to create a GraphQL wrapper for 89.5% of the APIs -- however, with limitations in many cases. A subsequent analysis of errors and warnings produced by OASGraph shows that missing or ambiguous information in the assessed OAS hinders creating complete wrappers. Finally, we present a use case of the IBM Watson Language Translator API that shows that small changes to an OAS allow OASGraph to generate more idiomatic and more expressive GraphQL wrappers.
JSON Pointer: draft-ietf-appsawg-json-pointer-04
  • C Paul
  • Kris Bryan
  • Zyp
Paul C. Bryan and Kris Zyp. 2012. JSON Pointer: draft-ietf-appsawg-json-pointer-04. https://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-04
JSON Reference: draft-pbryan-zyp-json-ref-03
  • C Paul
  • Kris Bryan
  • Zyp
Paul C. Bryan and Kris Zyp. 2012. JSON Reference: draft-pbryan-zyp-json-ref-03. https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03
Wrapping a REST API in GraphQL
  • Steven Luscher
Steven Luscher. 2016. Wrapping a REST API in GraphQL. https://graphql.org/ blog/rest-api-graphql-wrapper/
REST API design rulebook
  • Mark Massé
Mark Massé. 2012. REST API design rulebook. O'Reilly, Farnham.
The OpenAPI Specification: Version 3
  • Openapi Initiative
OpenAPI Initiative. 2018. The OpenAPI Specification: Version 3.0.2. https: //www.openapis.org