Chair of Software Engineering for Business Information Systems (sebis) Faculty of InformaticsTechnische Universität München wwwmatthes.in.tum.de
Model-Based Approach to Consume REST Services in Single Page ApplicationsNiklas Scholz - Final Presentation Master Thesis - 09.10.2017 Advisor: Adrian Hernandez-Mendez
Agenda
Motivation and Problem
Research Questions
Background
Approach
• Reference Architecture
• Meta-Model
• Code Generation Process
Live Demo
Evaluation
© sebis 2Niklas Scholz - Master Thesis Final Presentation
Consuming APIs in Single Page Applications
© sebis 4Niklas Scholz - Master Thesis Final Presentation
JIRA API
GitHub API
Frontend
JIRA Data Service
Controller
transform JIRA data
View
GitHubData Service
transform GitHub data
Scaling up number of APIs to consume
© sebis 5Niklas Scholz - Master Thesis Final Presentation
service 1
service 2
Frontend
Data Service 1Controller
transform data 1
View Data Service 2transform
data 2
transform data 3
transformdata 4
Data Service 3
Data Service 4
service 3
service 4
Scaling up number of APIs to consume
© sebis 6Niklas Scholz - Master Thesis Final Presentation
service 1
service 2
Frontend
Data Service 1
Controller
transform data 1
View
Data Service 2
transform data 2
transform data 3
transformdata 4
Data Service 3
Data Service 4
service 3
service 4
service 5
service 6
Data Service 5
Data Service 6
Data Service 7
Data Service 8
service 7
service 8
transform data 5
transform data 6
transform data 7
transformdata 8
Research Questions
© sebis 7Niklas Scholz - Master Thesis Final Presentation
What is the state-of-the-art in model-based RESTful API integration?
RQ1
Research Questions
© sebis 7Niklas Scholz - Master Thesis Final Presentation
What is the state-of-the-art in model-based RESTful API integration?
How does a model-based approach for RESTful API integration in single page applications look like?
RQ2
RQ1
Research Questions
© sebis 7Niklas Scholz - Master Thesis Final Presentation
What is the state-of-the-art in model-based RESTful API integration?
How does a model-based approach for RESTful API integration in single page applications look like?
What are the benefits and limitations of a model-driven approach for RESTful API integration?
RQ3
RQ2
RQ1
Analysing related work
© sebis 8Niklas Scholz - Master Thesis Final Presentation
• Lanthaler and Gütl: Hydra [1] • RESTful API description language
• Rossi: Model-driven REST API development [2] • Constricting model in UML and transforming it to RAML
• Modelling REST with the Eclipse Modelling Framework (EMF) • Ed-Douibi et al.: Ready-to-run web APIs out of data models [3] • Haupt et al.: Generate REST compliant services [4]
• Bonifacio et al.: NeoIDL [5] • domain specific language to specify RESTful APIs
Analysing the state-of-the-art
© sebis 9Niklas Scholz - Master Thesis Final Presentation
Web development frameworks
API Description
API Design Guidelines
API Management Tools
Process Steps
© sebis 10Niklas Scholz - Master Thesis Final Presentation
Reference Architecture
• Architecture to reduce complexity in client
• shift responsibility of RESTful API consumption outside of client
Reference Architecture
© sebis 11Niklas Scholz - Master Thesis Final Presentation
Single Page Application
Web Service 1
Web Service n
Web Service 2
Data Transformation
Query Service
Backend
Frontend
. . .
GraphQL API
RESTful API
RESTful API
RESTful API
Process Steps
© sebis 12Niklas Scholz - Master Thesis Final Presentation
Reference Architecture
Meta- Model
• Architecture to reduce complexity in client
• shift responsibility of RESTful API consumption outside of client
• Establishing meta-model describing consumption of RESTful services
Meta-Model
© sebis 13Niklas Scholz - Master Thesis Final Presentation
Query Service Model Query Service
name: Stringdescription: Stringauthor: Stringport: Int
Data ModelResolvername: Stringreturn type: String
API Request
body: String
Argumentname: Stringtype: Stringrequired: Boolean
11..*
0..*1..*Entity
name: String
Parametersname: Stringtype: String
1..*
1..*HTTP Method Authenticationusername: Stringpassword: String
Header Parametername: Stringvalue: String
1
GET
POST
PUT
DELETE
HEAD
OPTIONS
0..* 0..1
Query Paramersname: Stringvalue: String
0..*
URLprotocol: Stringhost: Stringpath: String
URI Paramers
name: String
0..*
1CONNECT
PATCH
TRACE
Process Steps
© sebis 14Niklas Scholz - Master Thesis Final Presentation
Reference Architecture
Meta- Model
Generation Process
• Architecture to reduce complexity in client
• shift responsibility of RESTful API consumption outside of client
• Establishing meta-model describing consumption of RESTful services
• Development of model-driven process to automatically generate RESTful API consumption
• Based on meta-model
Code Generation Process
© sebis 15Niklas Scholz - Master Thesis Final Presentation
Service Model (PIM)
model transformation(automated)
codegeneration
(automated)
GraphQL Service Model(PSM)
construct model using the editor
(semi-automated)Service Meta Model
coderefinement(manual)
source code
1 2
3
4
Process Steps
© sebis 16Niklas Scholz - Master Thesis Final Presentation
Reference Architecture
Meta- Model
Generation Process
Imple-mentation
• Architecture to reduce complexity in client
• shift responsibility of RESTful API consumption outside of client
• Establishing meta-model describing consumption of RESTful services
• Development of model-driven process to automatically generate RESTful API consumption
• Based on meta-model
• Implementation of process as a web application
• React app
Code Generation Tool - Workflow
© sebis 17Niklas Scholz - Master Thesis Final Presentation
API
1. What data and where to get it from?
Developer
Code Generation Tool - Workflow
© sebis 17Niklas Scholz - Master Thesis Final Presentation
API
1. What data and where to get it from?
2. Construction of model
Developer
Code Generation Tool - Workflow
© sebis 17Niklas Scholz - Master Thesis Final Presentation
API
1. What data and where to get it from?
2. Construction of model
3. Manual code refinement
generation of query service
Developer
Code Generation Tool - Workflow
© sebis 17Niklas Scholz - Master Thesis Final Presentation
API
1. What data and where to get it from?
2. Construction of model
3. Manual code refinement
generation of query service
4. Design UI
UI Designer
Developer
Code Generation Tool - Workflow
© sebis 17Niklas Scholz - Master Thesis Final Presentation
API
1. What data and where to get it from?
2. Construction of model
3. Manual code refinement
generation of query service
4. Design UI 5. Access query service to receive data
Data Transformation
Query Service
UI Designer
Developer
Process Steps
© sebis 19Niklas Scholz - Master Thesis Final Presentation
Reference Architecture
Meta- Model
Generation Process
Imple-mentation
Evaluation
• Architecture to reduce complexity in client
• shift responsibility of RESTful API consumption outside of client
• Establishing meta-model describing consumption of RESTful services
• Development of model-driven process to automatically generate RESTful API consumption
• Based on meta-model
• Implementation of process as a web application
• React app
• development of two example apps with tool
• comparison of two frontends (one with tool one without)
Evaluation - Comparing Two Frontends
© sebis 20Niklas Scholz - Master Thesis Final Presentation
project-detail.controller+ project: Project- getProject(id: String)
projects-list.controller+ projects: Project[]- getProjects()
projects-list.view
project-detail.view
project-data.service
+ getProjects(): Observable<Project[]>+ getProject(id: String): Observable<Project>
<<injects>>
<<injects>>
Frontend B
project-detail.controller+ project: Project- getProject(id: String)- transformProjectData(projectData: JSON)- transformRepoData(repoData: JSON)
projects-list.controller+ projects: Project[]- getProjects()- transformProjectsData(projects: JSON)
projects-list.view
project-detail.view
jira-data.service
+ getProjects(): Promise<any>+ getProject(id: String): Promise<any>
github-data.service
+ getRepository(repoName: String): Promise<any>
<<injects>>
<<injects>>
<<injects>>
Frontend A
Evaluation - Comparing Two Frontends
© sebis 20Niklas Scholz - Master Thesis Final Presentation
project-detail.controller+ project: Project- getProject(id: String)
projects-list.controller+ projects: Project[]- getProjects()
projects-list.view
project-detail.view
project-data.service
+ getProjects(): Observable<Project[]>+ getProject(id: String): Observable<Project>
<<injects>>
<<injects>>
Frontend B
project-detail.controller+ project: Project- getProject(id: String)- transformProjectData(projectData: JSON)- transformRepoData(repoData: JSON)
projects-list.controller+ projects: Project[]- getProjects()- transformProjectsData(projects: JSON)
projects-list.view
project-detail.view
jira-data.service
+ getProjects(): Promise<any>+ getProject(id: String): Promise<any>
github-data.service
+ getRepository(repoName: String): Promise<any>
<<injects>>
<<injects>>
<<injects>>
Frontend A
Evaluation - Comparing Two Frontends
© sebis 20Niklas Scholz - Master Thesis Final Presentation
project-detail.controller+ project: Project- getProject(id: String)
projects-list.controller+ projects: Project[]- getProjects()
projects-list.view
project-detail.view
project-data.service
+ getProjects(): Observable<Project[]>+ getProject(id: String): Observable<Project>
<<injects>>
<<injects>>
Frontend B
project-detail.controller+ project: Project- getProject(id: String)- transformProjectData(projectData: JSON)- transformRepoData(repoData: JSON)
projects-list.controller+ projects: Project[]- getProjects()- transformProjectsData(projects: JSON)
projects-list.view
project-detail.view
jira-data.service
+ getProjects(): Promise<any>+ getProject(id: String): Promise<any>
github-data.service
+ getRepository(repoName: String): Promise<any>
<<injects>>
<<injects>>
<<injects>>
Frontend A
Consuming multiple APIs leads to complexity in the client
Conclusions
© sebis 21Niklas Scholz - Master Thesis Final Presentation
Consuming multiple APIs leads to complexity in the client
Conclusions
© sebis 21Niklas Scholz - Master Thesis Final Presentation
The consumption of RESTful services can be modelled
Consuming multiple APIs leads to complexity in the client
Approach reduces complexity in client
Conclusions
© sebis 21Niklas Scholz - Master Thesis Final Presentation
The consumption of RESTful services can be modelled
Consuming multiple APIs leads to complexity in the client
Approach reduces complexity in client Limitation: Roundtrip Engineering
Conclusions
© sebis 21Niklas Scholz - Master Thesis Final Presentation
The consumption of RESTful services can be modelled
Consuming multiple APIs leads to complexity in the client
Approach reduces complexity in client Limitation: Roundtrip Engineering
Conclusions
© sebis 21Niklas Scholz - Master Thesis Final Presentation
The consumption of RESTful services can be modelled
References
© sebis 22Niklas Scholz - Master Thesis Final Presentation
[1] Markus Lanthaler and Christian Gütl. ‘Hydra: A vocabulary for hypermedia-driven web APIs’. In: CEUR Workshop Proceedings 996 (2013). issn: 16130073.
[2] Davide Rossi. ‘UML-based Model-Driven REST API Development’. In: Proceedings of the 12th International Conference on Web Information Systems and Technologies, Vol 1 (WEBIST) (2016), pp. 194–201. doi: 10.5220/0005906001940201.
[3] Hamza Ed-Douibi et al. ‘EMF-REST: Generation of RESTful APIs from Models’. In: Proceedings of the 31st Annual ACM Symposium on Applied Computing (2015), pp. 1446–1453. doi: 10.1145/2851613.2851782.
[4] Florian Haupt et al. ‘A model-driven approach for REST compliant services’. In: Proceedings - 2014 IEEE International Conference on Web Services, ICWS 2014 (2014), pp. 129–136. doi: 10.1109/ICWS.2014.30.
[5] Rodrigo Bonifacio et al. ‘NeoIDL: A Domain-Specific Language for Specifying REST Services’. In: International Conference on Software Engineering and Knowledge Engineering (2015), pp. 613–618. doi: 10.18293/SEKE2015-218.
Backup - Advantages
© sebis 23Niklas Scholz - Master Thesis Final Presentation
Lightweight Client
Focus on important steps
Advantages of MDSD
• Reducing complexity on client-side
• GraphQL queries
• not carried away with implemen-tation details
• Focus on UI
• consistency • reusability • development
speed • manageability
of complexity
Backup - Limitations
© sebis 24Niklas Scholz - Master Thesis Final Presentation
Roundtrip Engineering
Manual Code Refinement
Level of Abstraction
• Model not being stored
• Apply API changes manually
• Data transformation not modelled
• Developer has to add code manually
• only RESTful APIs
• model not entirely generic
Backup - Model Transformation Process
© sebis 25Niklas Scholz - Master Thesis Final Presentation
Resolvername: Stringreturn type: String
API Request
body: String
Argumentname: Stringtype: Stringrequired: Boolean
0..*1..*
HTTP Method Authenticationusername: Stringpassword: String
Header Parametername: Stringvalue: String
1 0..* 0..1
Query Paramersname: Stringvalue: String
0..*
URLprotocol: Stringhost: Stringpath: String
URI Paramers
name: String
0..*
1
Resolver Model GraphQL Schema
Backup - Query Service Architecture
© sebis 26Niklas Scholz - Master Thesis Final Presentation
server- port- app
schema- schema: String+ executableSchema: GraphQLSchema
resolvers+ resolveFunctions: JSON- makeAPIRequest(options, url, bodyData): Promise
<<use>>
<<use>>
Backup - Code Generation Tool Architecture
© sebis 27Niklas Scholz - Master Thesis Final Presentation
ui-components
<<use>>
<<use>>
modelTransformer+ transformToGraphQLModel(serviceModel: JSON): JSON- constructSchema(serviceModel: JSON): JSON- constructResolvers(serviceModel: JSON): JSON
coderGenerator+ renderSeverFiles(graphQLModel: JSON)
ResolversModel
AppControl+ handleGenerateServerButton(event: Event)
DataModelServiceConfig
DataEntity ResolverEntity
ApiRequest
11
* *
1
* mustachetemplates
<<use>>
Top Related