DaWeSearch — a Systematic Literature Review tool

Mshokry
4 min readAug 26, 2020

--

https://dawesearch.github.io/deploy/#/signup

Conducting a Systematic Literature Review(SLR) in cooperation with multiple researchers can become an organizational mess. And especially in times like during this Covid19 pandemic where people prefer working remotely at their home there is a need for a web application that facilitates conducting an SLR. For that reason we created DaWeSearch in supervision of the ISE professorship at TU Berlin. This article covers the technology and development decisions behind DaWeSearch.

Technologies

We will begin by discussing the tech stack since this project was part of a course where we would implement web applications via the serverless architecture. We decided to combine a MongoDB and AWS Lambda Functions that we deploy via the Serverless Framework in our backend and a single page app powered by vue.js with BootstrapVue in our frontend. The frontend communicates with our backend via the AWS API Gateway and from there on everything seems just like a Remote Procedure Call on an old fashioned RPC server.

Image 1: Outline of the technology usecases

Scope of the project

Down below you can see the scheme that common practice SLRs follow. The parts that are enframed by the turquoise rectangle define the scope of our project. In short DaWeSearch lets users look for publications in multiple literature databases at once, aggregates those that the user is interested in and then provides a rating/filtering system that enables cooperation with co-reviewers. To define specific functionalities in the development process we set out to introduce atomic user stories.

Image 2: SLR scheme

User stories

The user stories are assigned into the following epics:

“1. set up review”:

This epic includes the instantiation as well as the management of reviews. Another very important aspect of this epic is the review internal user management since every user is supposed to be able to rate selected publications separately.

“2. plan search”:

Includes integrated query building by combining search parameters. This epic intersects a lot with the label “wrapper” that was introduced later on and marks issues with our wrappers for the diverse literature database APIs.

“3. conduct search” (T6)

This epic deals with the combination of all our wrappers. The distribution of the query submitted by the user to all the wrappers at once and the aggregation of the retrieved results saves the user a lot of effort and time. There is even an implemented user story that defines the dismissing of duplicate retrieved publications.

“4. process search” (T7)

Part of this epic are the visualization of meta data for the retrieved results as well the option to persist publications and a collaborative scoring system to filter those persisted publications.

“ui”

Everything concerning the looks of the webpage. Later on this epic was misused to label every frontend task.

Control flow

After examining the SLR scheme(Image 2) and the collection of epics we defined a control flow that references every page view that we wanted to implement. One to log in first, then you land on an overview page for all the reviews that you participate in. When you want to work on a spefcific SLR you can chose to go to the “search page” or if you are already done with the search phase(take a look again at image 2 turquoise rectangle) enter the “score page”. Every one of the clickable objects in the control chart is an action that refers to an own AWS Lambda Function.

(Scroll down to take a look at the chart’s legend)

After conceptualizing this extensive plan all there was left to do for us was reading documentations, watching tutorials and a lot of trial and error. Especially CORS errors…

Conclusion

Before starting this project none of us ever created a serverless app. Obviously the concept of a web application running “without a server” was very confusing to us in the beginning. Now we gained some insight into this new technology and can confidently claim that running serverless is not actually that hard to grasp and implement. On the app developer side serverless seems to be just the next step in the seperation of concerns by abstraction.

Try out DaWeSearch

--

--