Towards a UML and IFML mapping to GraphQL

Editor's Notes

• #2: 15-17 minutes
• #3: Let’s begin by analyzing which are the main forces leading this work First of all, we consider Web APIs are first-class citizens on the Web, because most Web & Mobile apps make an extensive use of them to provide the user with live data and expanded functionality. At the same time, organizations all over the world have adopted Web APIs as the primary means to publish data on the Web.
• #4: However, Web APIs present some clear limitations: Server-side solutions and provide limited query capabilities Then response payloads get larger as requirements grew. Although different apps present different requirements, the most common solution is to return the same response to all those different clients As a result, performance quickly becomes an issue in two distinct ways. Firstly, mobile app sometimes struggle with the amount of effort it take to parse, deserialize, and store ever-growing JSON data. Secondly, composing those large JSON files imply more hits to DBs.
• #5: In order to partially alleviate those issues, FB has recently released GraphQL, which is a kind of DSL on top of your own backend data fetching logic. It does not connect directly to a database. It provides a way to describe a request for structured data, but it is then up to your backend to fulfill that request. GraphQL is not just for APIs access, it may replace them. But we plan to use it as a uniform data access over Web APIs mainly. GraphQL can fix the aforementioned performance problems because clients can now request only the data they need and the response then suppose to fetch just relevant data.
• #6: Let’s review now how MDE has been used for more than a decade in Web Engineering. MDE approaches widely used in the web engineering community to simplify app development. Even, some of them have been extended to support REST APIs for data publication. However, not enough done to really enable the publication and consumption of open data on the Web. Limitation: MDE tools fall short especially when integrating heterogeneous data backends, which are usually performed in an ad-hoc manner.
• #7: Why not use GraphQL to implement the integration of heterogeneous backends in a systematic way? In order to follow a MDE approach, we think we can easily extend current MDE tools for Web Engineering to generate GraphQL specifications from client-side development artifacts as UML and IFML. Data Model (UML) --> GraphQL Schema Data Interaction (IFML) --> GraphQL Schema Alternative: from Web APIs (more complex problem). There might be other alternatives but we are presenting that approach in this work. Key tool to facilitating the exploitation of online data sources. At the end GraphQL is a technology partially supporting our ideas of Web APIs integration. Two-way interaction: query & mutation.
• #8: From a MDE perspective, we decide to implement such process into Eclise Modeling Framework, so we can build and deploy an Eclipse plugin. Previously, we had to define an Xtext grammar from the GraphQL specification by FB. We did it by studying such specification and defining a Xtext Grammar which produces a GraphQL metamodel as by-product. Such GraphQL metamodel is useful to define the mapping as a model2model transformation. Talk about issues to get the specification of GraphQL IDL?
• #9: As an illustrative example we have partially modeled with UML and IFML a Web application resembling the star wars example from GraphQL specification. So in this case, we have defined a UML class diagram to represent the data model of this example, concerning human and droid characters, starships and so on. Additionally, we have modeled a basic interaction scenario by IFML so that the user can browse the heroes of the different episodes (in a traditional master/slave pattern) of the saga and they can also add reviews to a concrete episode.
• #10: From the UML class diagram we can extract the fundamental structure of the graphql schema which is basically defined as a graph of Type Objects. One of the main problems to solve is that hierarchies are not supported in GraphQL, a strategy to flatten these hierarchies (view in paper). For example, red box, from every interface or abstract class in UML, we generate an interface in GraphQL, as shown. Character abstract class becomes Character interface in GraphQL. All its properties and relationships are transformed into object members. Note that onetomany relationships generate members of type array. While, blue box is highlighting the generation of a type object from a UML class, whose members generation follows the same rules as before. Note that in GraphQL all the members of the implemented interface have to be redefined within the type object.
• #11: From the IFML model we can extract how that GraphQL schema would be used by means of queries and mutations. Every GraphQL has a query type and may have an additional mutation type as root types. They are defined as regular object types, but they are special because they define the entry point of every GraphQL query or mutation. In particular, GraphQL queries and mutations can be generated out of View Component definitions in the IFML model. {«list»} and \emph{«details»} stereotypes become queries since they define a view over a data entity by filtering which data objects to show (parameter binding) and which attributes to present (fields). Additionally, \emph{«form»} stereotyped view components would be transformed into mutations and input types, which collects the data fields parameterizing the invoked mutation. In our example, the \emph{«form»} view component and its associated action \texttt{Add} are transformed into the mutation \texttt{createReview} which is listed in the \texttt{Mutation} type (root mutation) of the resulting GraphQL schema.
• #13: This work I’ve just presented today is not more than a small milestones in a challenging project: ODA, whose main motto is ...
• #14: If you are interested, please get in touch Thank you very much for your attention