A GraphQL server contains two building blocks: (1) a GraphQL schema defining the types of data objects that can be requested; (2) resolver functions fetching the relevant data from underlying data sources. GraphQL can be used for data integration if the GraphQL schema provides an integrated view of data from multiple data sources, and the resolver functions are implemented accordingly. However, there does not exist a semantics-aware approach to use GraphQL for data integration. We proposed a framework using GraphQL for data integration in which a global domain ontology informs the generation of a GraphQL server. Furthermore, we implemented a prototype of this framework, OBG-gen. In this paper, we demonstrate OBG-gen in a real-world data integration scenario in the materials design domain and in a synthetic benchmark scenario.
CEUR ceur-ws.org
GraphQL1 is a conceptual framework for building Web APIs. The framework introduces a so-called GraphQL schema (Figure 1a) that defines the types of data objects that can be requested, and resolver functions (Figure 1b) that specify how to retrieve and fetch data from underlying data sources. Another building block of the framework is the GraphQL query language for expressing data retrieval requests (Figure 1c). The example schema contains an object type (U n i v e r s i t y ) with a field definition
U n i v e r s i t y I D of which the value type is S t r i n g and a field definition d e p a r t m e n t s of which the value type is [ D e p a r t m e n t ] . It also contains two input object types (U n i v e r s i t y F i l t e r and S t r i n g F i l t e r ) which can capture the notions of filter expressions. For instance, the query accepts the argument (U n i v e r s i t y I D : { _ e q : “ u 1 ” } ) according to the https://www.ida.liu.se/~patla00/ (P. Lambrix) CEUR Workshop Proceedings http://huanyuli.se (H. Li); https://olafhartig.de (O. Hartig); https://rickard.armiento.se (R. Armiento); © 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). type University {
UniversityID: String departments: [Department] } input UniversityFilter {
UniversityID: StringFilter _and: [UniversityFilter] } input StringFilter { _eq: String _in: [String] } type Query {
UniversityList(filter: UniversityFilter): [University] } const UniversityList = (uid) => { /*assume the underlying data source is a relational database containing a table named university with an id column*/ let data = db_connection.select().from(
‘university’).where(‘id’, uid); /*assume University is an object defined
according to the type in the schema*/ let allUniversities = data.then(rows =>
new University(rows[0])); return allUniversities; }; { } { } UniversityList( filter:{
UniversityID:{_eq:“u1”} }) } departments { head (a) GraphQL schema example.
(b) Resolver function example.
(c) Query example.
U n i v e r s i t y F i l t e r definition, which represents “ UniversityID is equal to ‘u1’”. Additionally,
GraphQL schema presumes the Q u e r y type as the query root operation type. The example
schema has the U n i v e r s i t y L i s t field definition of which the returned type is [ U n i v e r s i t y ] , a
list of universities. GraphQL can be used for data integration by building a GraphQL server
over underlying data sources where the GraphQL schema provides an integrated view of data,
and the resolver functions specify implementations for accessing data sources. However, there
does not exist a semantics-aware approach to employ GraphQL for data integration. It means
the developer needs to write program code (i.e., resolver functions) to populate the various
elements of a GraphQL schema. In our previous work, we provided a semantics-aware approach
to employ GraphQL for data integration which is a global as view approach [
2All the material related to OBG-gen is available online at https://github.com/LiUSemWeb/OBG-gen.
GraphQL Query Answering Process (4) (1)
Our schema generator (as shown in Algorithm 1) first iterates over the concept Algorithm 1: Schema Generator names. For each concept (e.g., U n i v e r s i t y ), IOnuptuptut :: aa sGertaopfhcQoLncsecphtesm,Ca; a set of GCIs, G the concept name is used as the name of 12 for ∈extCenddo with an empty object type, type to be generated in the GraphQL schema 3 extend with an empty input type, Filter (U n i v e r s i t y ); the term concatenated with ‘Fil- 4 add field/argument declarations to the Query type 5 for ∈ G do ter’ is used as the name of an input type to be 6 if is of the form P ⊑ Q then generated (U n i v e r s i t y F i l t e r ); the term con- 78 eexxtteenndd wwiitthh aann ienmpputtytyinptee,rfaFcielttyepre, catenated with ‘List’ is used as the name of a 9 extend with field/argument declarations to the Query type ifeld of the Q u e r y type (U n i v e r s i t y L i s t ). Ad- 10 extend with declaration that implements ditionally, each such field of the Q u e r y type 11 else is assigned an argument named ‘filter’, with 12 /* is of the other forms */ a type that is the corresponding input type 13 extend with field declarations to , Filter (e.g., f i l t e r : U n i v e r s i t y F i l t e r to U n i v e r s i t y L i s t ). In the next step, the algorithm iterates over GCIs. Taking such a GCI, U n i v e r s i t y ⊑ ∀ d e p a r t m e n t s .D e p a r t m e n t , as an example, the algorithm generates field definitions d e p a r t m e n t s : [ D e p a r t m e n t ] of the U n i v e r s i t y type, and d e p a r t m e n t s : [ D e p a r t m e n t F i l t e r ] of the U n i v e r s i t y F i l t e r type. For a GCI U n i v e r s i t y ⊑ = 1 U n i v e r s i t y I D .S t r i n g , the algorithm generates field definitions U n i v e r s i t y I D : S t r i n g of the U n i v e r s i t y type, and U n i v e r s i t y I D : S t r i n g F i l t e r of the U n i v e r s i t y F i l t e r type.
The generic resolver function includes technical components QueryParser and Evaluator as shown in Figure 3a. The QueryParser parses a query including a filter expression given as an input argument, and outputs the corresponding abstract syntax trees (ASTs) for the input argument and the query structure, respectively. Figure 3b shows example ASTs for a filter expression and a query structure according to the query example in Figure 1c. The QueryParser parses the query, converts a filter expression into a union of conjunctive expressions (arrow ⃝ 1 ), and generates an AST for each conjunctive expression and an AST for the query structure (arrow ⃝ 2 ). Then, the filter expressions (frame ⃝ a ) and the query fields (frame ⃝ b ) are evaluated. The Evaluator is responsible for sending requests to underlying data sources and fetching data according to an AST. During evaluation of the filter expression, for each AST representing a conjunctive (sub-)expression, an evaluator is called to request data satisfying the conjunctive (sub-)expression. After a call to an evaluator based on an AST, data representing the requested type, which contains identifier information, is returned. During evaluation of the query fields, the identifier information is an input in the call to the evaluator (arrow ⃝ 3 ). Taking the query in (a) Outlined generic resolver function. (b) Example Abstract Syntax Trees.
We demonstrate OBG-gen in a real-world data integration scenario in the materials design
domain and in a synthetic benchmark scenario, Linköping GraphQL Benchmark (LinGBM) [
This paper has briefly introduced the OBG-gen, a prototype implementation for generating GraphQL servers. Using OBG-gen, GraphQL application developers can avoid constructing GraphQL servers from scratch. In the future, we will work on supporting more query features (e.g., order by) in the generic resolver function; follow the development of the GraphQL language and explore the possibility of formally generating new features based on ontologies.