Is a Dataframe Just a Table?

Querying data is core to databases and data science. However, the two communities have seemingly different concepts and use cases. As a result, both designers and users of the query languages disagree on whether the core abstractions - dataframes (data science) and tables (databases) - and the operations are the same. To investigate the difference from a PL-HCI perspective, we identify the basic affordances provided by tables and dataframes and how programming experiences over tables and dataframes differ. We show that the data structures nudge programmers to query and store their data in different ways. We hope the case study could clarify confusions, dispel misinformation, increase cross-pollination between the two communities, and identify open PL-HCI questions

IMPLEMENTATION AND EVALUATION OF A GRAPHQL-BASED WEB APPLICATION FOR PROJECT FOLLOW UP

This thesis is about APIs and web development. Technologies specifically presented include GraphQL and REST as a basis for the implementation of the web application. The purpose of the thesis was to create a web-based tool for project follow up. The main goal of the tool is to provide reporting functionalities and views for project follow up based on data from the public APIs provided by Toggl. In the first part of the thesis, relevant theory about GraphQL, REST and APIs is provided. Web APIs are presented, along with common protocols, such as HTTP, as well as different data formats for the serialization of the data to be transmitted over the net-work. A literature review is also performed on the current state of the research on GraphQL-based APIs as well as on comparisons on GraphQL-, and RESTful-APIs. The second part consists of the design and implementation of the application. Toggl, a time tracking service, is described with its two different APIs, the Toggl API, and the Report API. Further, the decision process of selecting the technologies for the developed tool is presented. One of the main parts of the tool consists of the synchronization mechanism for keeping the data in the database up to date with the data stored in Toggl. The other major part is about exposing the data via a GraphQL-API and consuming it in a single-page-application created in React. The developed application is a minimum viable product, fulfilling its purpose of providing reporting functionalities for projects based on the data provided by Toggl. It was developed with usability, flexibility and testability in mind enabling further development in the future. GraphQL was the choice of API technology and was considered a suitable approach in this applicatio

API diversity for microservices in the domain of connected vehicles

Web services in the domain of connected vehicles are subject to various requirements including high availability and large workloads. Microservices are an architectural style which can fulfill those requirements by fostering the independence and decoupling of software components as reusable services. To achieve this independence, microservices have to implement all aspects of providing the services themselves, including different API technologies for heterogeneous consumers and supporting features like authentication. In this work, we examine the use of a service proxy that externalizes these concerns into a sidecar that provides multiple APIs and common service functionality in a platform-independent manner. We look at how different kinds of API styles and technologies solve selected classes of problems and how we can translate between API technologies. We design and implement a framework for building gateways that enables the creation and composition of reusable components, in the fashion of Lego bricks, to maximize flexibility, while reducing the effort for building gateway components. We design and implement selected components of common and reusable API functionality enabling us to build a reference setup with a service proxy as a sidecar using our framework. Finally, we evaluate the proposed solution to identify benefits and drawbacks of the approach of using our framework as a service proxy. We conclude that the examined approach provides benefits for the development of many polyglot microservices, but splitting one service into two components adds additional complexity that has to be managed.Web Services für vernetzte Fahrzeuge unterliegen unterschiedlichen Anforderungen, unter anderem einer hohen Verfügbarkeit und einem großen Datendurchsatz. Microservices sind ein Architekturstil, der diesen Anforderungen gerecht werden kann, indem er die Unabhängigkeit und Entkopplung von Softwarekomponenten als wiederverwendbare Services fördert. Zum Erreichen der Unabhängigkeit implementieren Microservices alle Aspekte der Servicebereitstellung eigenständig. Dazu gehört verschiedene API Technologien für heterogene Clients bereitzustellen und unterstützende Funktionalität wie Authentifizierung zu implementieren. In dieser Arbeit wird die Verwendung einer Proxy Komponente vor einem Service untersucht, durch welche die Bereitstellung verschiedener API Technologien und allgemeiner unterstützender Funktionalität aus dem Service extrahiert wird. Die Lösungen verschiedener API Technologien und Stile für ausgewählte Klassen an Problemen werden verglichen und mögliche Umwandlungen der verschiedenen API Technologien werden untersucht. Es wird ein Framework konzeptioniert und implementiert, das die Erstellung von Gateways durch Kombination von wiederverwendbaren Komponenten, wie das Zusammensetzen von Legosteinen, ermöglicht. Dieses Framework sorgt für eine hohe Flexibilität, während es den Aufwand bei der Erstellung von Gateways gering hält. Es werden ausgewählte wiederverwendbare Komponenten entworfen, um eine Referenzimplementierung des Ansatzes umzusetzen, bei der allgemeine Funktionalität in einen parallel laufenden Proxy ausgelagert wird. Dieser Ansatz wird evaluiert, indem Vor- und Nachteile anhand eines mit dem Framework erstellten Proxys identifiziert werden. Das Fazit dieser Arbeit ist, dass dieser Ansatz bei Systemen mit vielen Microservices mit unterschiedlichen Programmiersprachen Vorteile bringt, aber die Trennung eines Services in zwei Komponenten eine nicht unerhebliche Komplexität einführt

A Mechanized Formalization of GraphQL

International audienceGraphQL is a novel language for specifying and querying web APIs, allowing clients to flexibly and efficiently retrieve data of interest. The GraphQL language specification is unfortunately only available in prose, making it hard to develop robust formal results for this language. Recently, Har-tig and Pérez proposed a formal semantics for GraphQL in order to study the complexity of GraphQL queries. The semantics is however not mechanized and leaves certain key aspects unverified. We present GraphCoQL, the first mechanized formalization of GraphQL, developed in the Coq proof assistant. GraphCoQL covers the schema definition DSL, query definitions, validation of both schema and queries, as well as the semantics of queries over a graph data model. We illustrate the application of GraphCoQL by formalizing the key query transformation and interpretation techniques of Hartig and Pérez, and proving them correct, after addressing some imprecisions and minor issues. We hope that GraphCoQL can serve as a solid formal baseline for both language design and verification efforts for GraphQL

ProGS: Property Graph Shapes Language (Extended Version)

Property graphs constitute data models for representing knowledge graphs. They allow for the convenient representation of facts, including facts about facts, represented by triples in subject or object position of other triples. Knowledge graphs such as Wikidata are created by a diversity of contributors and a range of sources leaving them prone to two types of errors. The first type of error, falsity of facts, is addressed by property graphs through the representation of provenance and validity, making triples occur as first-order objects in subject position of metadata triples. The second type of error, violation of domain constraints, has not been addressed with regard to property graphs so far. In RDF representations, this error can be addressed by shape languages such as SHACL or ShEx, which allow for checking whether graphs are valid with respect to a set of domain constraints. Borrowing ideas from the syntax and semantics definitions of SHACL, we design a shape language for property graphs, ProGS, which allows for formulating shape constraints on property graphs including their specific constructs, such as edges with identities and key-value annotations to both nodes and edges. We define a formal semantics of ProGS, investigate the resulting complexity of validating property graphs against sets of ProGS shapes, compare with corresponding results for SHACL, and implement a prototypical validator that utilizes answer set programming