VIETNAM NATIONAL UNIVERSITY
HO CHI MINH CITY UNIVERSITY OF TECHNOLOGY
FACULTY OF COMPUTER SCIENCE AND ENGINEERING

GRADUATION THESIS

Design and build a website for
Medical Doctor Office Management

Council:
Instructor:
Reviewer:
Student:

CLC Computer Science 4
Prof. Nguyen Duc Thai
Prof. Nguyen Le Duy Lai
Nguyen Quang Truong - 1713753

HO CHI MINH CITY, October 2021


I HC QUC GIA TP.HCM
---------TRNG I HC BỗCH KHOA
KHOA: KH & KT M‡y t’nh ___
BỘ MïN: HT & MMT _______

CỘNG HđA XÌ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập - Tự do - Hnh phc

NHIM V LUN ỗN TT NGHIP

Ch ý: Sinh vi•n phải d‡n tờ nˆy vˆo trang nhất của bản thuyết tr“nh

HỌ VË TæN: Nguyễn Quang Trường
NGËNH: Computer Science

MSSV: 1713753
LỚP:

1. Đầu đề luận ‡n:
Design and Build A Website for Medical Doctor Office Management
2. Nhiệm vụ (y•u cầu về nội dung vˆ số liệu ban đầu):
¥! Do research on works related to medical doctor office management.
¥! Complete requirement analyses on the mentioned website, using UML
¥! Provide website design, including interface design, interaction design, database
design, authentication design É
¥! Apply SEO, Google Maps design to the website.
¥! Build search feature for website.
¥! Implement the website with appropriate programming languages and technologies.
3. Ngˆy giao nhiệm vụ luận ‡n: 01/03/2021
4. Ngˆy hoˆn thˆnh nhiệm vụ: 01/08/2021
5. Họ t•n giảng vi•n hướng dẫn: Nguyễn Đức Th‡i

Phần hướng dẫn:

Nội dung vˆ y•u cầu LVTN đ‹ được th™ng qua Bộ m™n.
Ngˆy 01 th‡ng 03 năm 2021
CHỦ NHIỆM BỘ MïN

GIẢNG VIæN HƯỚNG DẪN CHêNH


(Ký vˆ ghi r› họ t•n)

(Ký vˆ ghi r› họ t•n)

Nguyễn Đức Th‡i
PHẦN DËNH CHO KHOA, BỘ MïN:
Người duyệt (chấm sơ bộ): ________________________
Đơn vị: _______________________________________
Ngˆy bảo vệ: ___________________________________
Điểm tổng kết: _________________________________
Nơi lưu trữ luận ‡n: _____________________________

Nguyễn Đức Th‡i


TRNG I HC BỗCH KHOA
KHOA KH & KT MỗY TờNH

CNG HđA XÌ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập - Tự do - Hạnh phœc
---------------------------Ngˆy 10 th‡ng 08 năm 2021

PHIẾU CHẤM BẢO VỆ LVTN
(Dˆnh cho người hướng dẫn/phản biện)
1. Họ vˆ t•n SV: Nguyễn Quang Trường
MSSV: 1713753
Ngˆnh (chuy•n ngˆnh): Computer Science
2. Đề tˆi: Design and Build A Website for Medical Doctor Office Management
3. Họ t•n người hướng dẫn: Nguyễn Đức Th‡i
4. Tổng qu‡t về bản thuyết minh:

Số trang:
Số chương:
Số bảng số liệu
Số h“nh vẽ:
Số tˆi liệu tham khảo:
Phần mềm t’nh to‡n:
Hiện vật (sản phẩm)
5. Tổng qu‡t về c‡c bản vẽ:
- Số bản vẽ:
Bản A1:
Bản A2:
Khổ kh‡c:
- Số bản vẽ vẽ tay
Số bản vẽ tr•n m‡y t’nh:
6. Những ưu điểm ch’nh của LVTN:
¥! Website runs properly with most required featues
7. Những thiếu s—t ch’nh của LVTN:
¥! The final report contains many mistakes.
¥! No software testing performed at all.
¥! No SEO (Search Engine Optimization) presented at all.
¥! Student did not follow the instructions of the supervisor.
¥! Student did not submit the final report to the supervisor before presentation in the committee
for content checking.
8. Đề nghị: Được bảo vệ R
Bổ sung th•m để bảo vệ o
9. 3 c‰u hỏi SV phải trả lời trước Hội đồng:
a.

Kh™ng được bảo vệ o


b.
c.
10. Їnh gi‡ chung (bằng chữ: giỏi, kh‡, TB):

Điểm :

7/10

Ký t•n (ghi r› họ t•n)

Nguyễn Đức Th‡i


VIETNAM NATIONAL UNIVERSITY HO CHI MINH CITY
HO CHI MINH CITY UNIVERSITY OF TECHNOLOGY
FACULTY OF COMPUTER SCIENCE AND ENGINEERING

SOCIALIST REPUBLIC OF VIETNAM
Independence - Freedom – Happiness

---------------------------09 Aug 2021.

Thesis Review Report
(For instructors/reviewers)
1. Student's full name: NGUYEN QUANG TRUONG
Student ID: 1713753
Major (specialty): Computer Science
2. Subject: Design and building a website for Medical Doctor Office Management
3. Full name of Supervisor/Reviewer: NGUYEN LE DUY LAI
4. Overview of the Thesis:

Page number:
Chapter number:
Number of data tables:
Number of figures:
Number of Reference:
Computation software:
Artifacts (products):
5. Overview of drawings:
- Number of drawings:
Version A1:
Version A2:
Other size:
- Number of hand-drawn drawings
- Number of drawings on the computer:
6. Main advantages of the Thesis:
Research Objectives:
• Patient needs a trustworthy resource with various options for them to choose the most suitable doctor.
• Doctor can expand their network to the potential customers and manage appointments with patients.
Proposed Solution
• The thesis proposed to create a Website with a user-friendly interface for everyone who can easily access
on any device, from everywhere with a browser. An authentication mechanism integrated to the Website
permits a privacy for the stored information.
• The deliverable of this thesis is an operational Website with a list of features in the design. All features are
implemented to provide users with a great experience in the Website. The Website has been successfully
deployed and users can access through any device’s browser.
7. Main shortcomings of the Thesis:
• The structure of the Website design is not clear; the data flow needs to be given with more details.
• The search and match tool implemented in the Website is quite simple.
• The Website needs implementing a stronger method for the authentication because users can store sensitive
information.

8. Recommend: Permit to defend  Permit to defend with condition  Not-allowed 
9. Three questions student must answer in front of the Committee:
a. What do you think about a stronger authentication method? Have you surveyed for different
authentication mechanisms?
b. In term of Website implementation and exploration, what do you think about the material requirements
and hardware resource?
c. How do you plan to get back the benefits from Website exploitation?
10. Overall assessment (in words: good, quite good, average):
Score: 7.5/10.
Sign and full name.


Declaration Of Authenticity

I declare that this research is my own work, conducted under the supervision
and guidance of Prof. Nguyen Duc Thai. The result of our research is legitimate
and has not been published in any forms prior to this. All materials used within
this researched are collected myself by various sources and are appropriately listed
in the references section.
In addition, within this research, I also used the results of several other
authors and organizations. They have all been aptly referenced.
In any case of plagiarism, I stand by my actions and will be responsible for
it. Ho Chi Minh city University of Technology therefore are not responsible for
any copyright infringements conducted within our research.
Ho Chi Minh City, Oct 2021
Author
Nguyen Quang Truong

4



Acknowledgement

I am using this opportunity to express my gratitude to everyone who supported me during my study and my life. I am thankful for their aspiring guidance
invaluably constructive criticism and friendly advice.
I offer my sincerest and deepest gratitude to my supervisor, Professor
Nguyen Duc Thai, for his support and guidance throughout my thesis. He was
always ready to provide answers to my puzzling questions and guided my work to
a swift end.
Finally, I recognize that this research would not have been possible without
the support from my family and from bottom of my heart, I must acknowledge
my parents without whose love, encouragement and sacrifice, I would not have
finished this thesis.

5


Abstract

Design and building a website for Medical Doctor Office Management
by
Nguyen Quang Truong
Ho Chi Minh City University of Technology, Oct 2021

The aim of this thesis is to develop a web application designated for communication
between patient and doctor, and to describe the whole process of its development.
The thesis contains a description of application analysis with design, implementation and application testing. Besides the description of the development process,
the final output of the thesis is also working web application.



Contents

1 Introduction

9

1.1

Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2

Research Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3

Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4

Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Related Works

12

3 Theoretical Knowledge


15

3.1

3.2

Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1

HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2

CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3

TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1

NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1


CONTENTS

3.2.2


CONTENTS

3.2.1.1

What is SQL? . . . . . . . . . . . . . . . . . . . . . 17

3.2.1.2

Types of NoSQL Databases . . . . . . . . . . . . . 17

GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2.1

Fields . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2.2

Arguments . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2.3

Object types . . . . . . . . . . . . . . . . . . . . . 19

4 Technology
4.1

21

Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1


Angular Concepts . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.2

Project File Structure . . . . . . . . . . . . . . . . . . . . . 23

4.2

Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3

Amazon Cognito . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4

Amazon DynamoDB . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.5

AWS Amplify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5.1

GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5.1.1

Define a model type . . . . . . . . . . . . . . . . . 29

4.5.1.2


Authorization rules . . . . . . . . . . . . . . . . . . 29

5 Design
5.1

31

Use-case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2


CONTENTS

CONTENTS

5.1.1

Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1.2

Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.3

Verify Doctor . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.4


Create Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.5

Update Schedule . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.6

Search Doctor . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.7

View Doctor Profile . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.8

Booking Appointment . . . . . . . . . . . . . . . . . . . . . 40

5.1.9

Cancel Appointment . . . . . . . . . . . . . . . . . . . . . . 42

5.1.10 Manage Appointment . . . . . . . . . . . . . . . . . . . . . . 42
5.1.11 Review Doctor . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.12 Forgot Password . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.13 Update Information . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.14 Change Password . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2

GraphQL Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.1

Patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.2

Doctor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.3

Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2.4

Booking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3


CONTENTS

5.3

CONTENTS

UI Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3.1

Navigation bar component(Header) . . . . . . . . . . . . . . 53


5.3.2

Search component . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3.3

Login form component . . . . . . . . . . . . . . . . . . . . . 54

5.3.4

Sign up form component . . . . . . . . . . . . . . . . . . . . 56

5.3.5

User info component . . . . . . . . . . . . . . . . . . . . . . 58

5.3.6

Doctor-card Component . . . . . . . . . . . . . . . . . . . . 60

5.3.7

Review Component . . . . . . . . . . . . . . . . . . . . . . . 61

5.3.8

Booking Component . . . . . . . . . . . . . . . . . . . . . . 62

5.3.9


User Dashboard Component . . . . . . . . . . . . . . . . . . 64

5.3.10 Patient Appointment Component . . . . . . . . . . . . . . . 65
5.4

System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Implementation

67

6.1

Authentication & Authorization . . . . . . . . . . . . . . . . . . . . 67

6.2

Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.1

Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2.2

Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2.3

Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72


6.2.4

Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4


CONTENTS

CONTENTS

6.2.5

Doctor’s profile page . . . . . . . . . . . . . . . . . . . . . . 74

6.2.6

Booking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.2.7

User Information . . . . . . . . . . . . . . . . . . . . . . . . 76

6.2.8

Manage User . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.3

Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


7 Conclusion

84

7.1

Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.1

Drawback . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

7.2.2

Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5


List of Figures

2.1

Homepage of fvhospital.com . . . . . . . . . . . . . . . . . . . . . . 13

2.2


Homepage of khambacsi.com . . . . . . . . . . . . . . . . . . . . . . 14

3.1

GraphQL Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2

GraphQL Argument Example . . . . . . . . . . . . . . . . . . . . . 19

3.3

GraphQL Argument Example . . . . . . . . . . . . . . . . . . . . . 19

3.4

GraphQL Schema Example

4.1

Angular Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2

File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3

Bootstrap Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


4.4

Amazon Cognito Diagram . . . . . . . . . . . . . . . . . . . . . . . 26

4.5

Amazon DynamoDB Example . . . . . . . . . . . . . . . . . . . . . 27

5.1

Use-case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2

Navigation bar component . . . . . . . . . . . . . . . . . . . . . . . 53

. . . . . . . . . . . . . . . . . . . . . . 19

6


LIST OF FIGURES

LIST OF FIGURES

5.3

Navigation bar for registered user . . . . . . . . . . . . . . . . . . . 53


5.4

Search Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.5

Login form Component . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.6

Login form alert message . . . . . . . . . . . . . . . . . . . . . . . . 55

5.7

Login form alert wrong password . . . . . . . . . . . . . . . . . . . 56

5.8

Picking role for signing up . . . . . . . . . . . . . . . . . . . . . . . 56

5.9

Alert message for picking role . . . . . . . . . . . . . . . . . . . . . 57

5.10 Sign up form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Alert message for using existed email for signing up . . . . . . . . . 58
5.12 Successfully sign up . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.13 Adding information for patient

. . . . . . . . . . . . . . . . . . . . 59


5.14 Adding information for doctor . . . . . . . . . . . . . . . . . . . . . 60
5.15 Doctor-card Component . . . . . . . . . . . . . . . . . . . . . . . . 60
5.16 Review Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.17 Booking Component . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.18 Booking Component with pop up . . . . . . . . . . . . . . . . . . . 63
5.19 User Dashboard component . . . . . . . . . . . . . . . . . . . . . . 64
5.20 Patient Appointment Component . . . . . . . . . . . . . . . . . . . 65
5.21 Website’s system architecture . . . . . . . . . . . . . . . . . . . . . 66

7


LIST OF FIGURES

LIST OF FIGURES

6.1

Amazon Cognito Function . . . . . . . . . . . . . . . . . . . . . . . 68

6.2

JWT Token when login successfully . . . . . . . . . . . . . . . . . . 68

6.3

JWT Token attributes . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.4


User group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.5

Routing map of website

6.6

Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.7

Login Page

6.8

Register Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.9

Search Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

. . . . . . . . . . . . . . . . . . . . . . . . 71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.10 Doctor’s profile Page . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.11 Booking Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.12 User Information page . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.13 Manage User Page . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.1

Homepage of deployed web application . . . . . . . . . . . . . . . . 85

8


Chapter 1
Introduction
1.1

Problem Statement
Medical care is one of the most essential aspect in life cause it definitely

affect everyone’s health in any shape or form. And that’s itself in fact need an extra
public attention. The majority of people in Vietnam access medical care by the
traditional way is public hospital due to its popularity and technology it holds. And
for that reason, the number of patients each doctor has to treat daily is massive
and can not exceed time limited allowed per patient. Therefore, the demand for
new treatment is rising, patient wants to establish a long term relationship with
their close doctor who is going to understand deeply their medical condition which
will beneficial for the future diagnosis and prevention of dangerous diseases. The
patient still takes the blood test, urine test, supersonic,.. at the hospital but they
take that result to their close doctor for the diagnosis and receive medicine bill
from them as well.
The majority of patients find doctors through the suggestion of their acquaintances or their close friends who had a few sessions with a doctor and comfortable to recommend he/she to them. In that case, if the patients’ circle do not
9



1.2. RESEARCH OBJECTIVE

CHAPTER 1. INTRODUCTION

have any connection with the doctor, it is very difficult for them to find a qualified
doctor cause there is very limited of resource online for searching doctor’s information also the question about the authentication of the doctor whether they are
trustworthy or not?

1.2

Research Objective

• Patient needs a trustworthy resource with various options for them to choose
the most suitable doctor for their need.
• Doctor can to expand their network to the potential customer and manage
appointments with patient.

1.3

Proposed Solution
In order to fulfill the objectives of the above section and answer the problems

addressed in the problem statement section, I propose to create a website with a
friendly user interface for everyone can easily access on any device, browser from
everywhere. With an authenticate system to guarantee every piece of information
in the website is legit.

1.4

Thesis Structure

The next parts of this thesis are composed of six chapters as follow:
Chapter two provide some related projects with their pros and cos
Chapter three introduce some background knowledge.

10


1.4. THESIS STRUCTURE

CHAPTER 1. INTRODUCTION

Chapter four lists all technologies were used in this thesis.
Chapter five presents the design for the system.
Chapter six shows the implementation of the thesis and how the result is
formed.
Chapter seven gives an overview about the result and discuss some future
improvements.

11


Chapter 2
Related Works
In domestic, the majority of website which shows doctor’s information belong to the particular hospitals. And the only way to book the appointment is
through the hospital, and the process is very much similar with conventional way
with no improvement. Take the website www.fvhospital.com from FV hospital
located at Ho Chi Minh City as example. The website still provides the large
amount of information but the doctors solely works for that hospital, therefore
the patient can only book with the hospital rather than booking directly from the
doctor.


12


CHAPTER 2. RELATED WORKS

Figure 2.1: Homepage of fvhospital.com

Next, the third-party website www.khambacsi.com which does not restrict with any organization, they showcase the diverse doctors from every city in
the country. The limitation of this website is there is no review system for patients
to consider beside the doctor’s background. User need to know the experiences of
previous customers to make a final decision.

13


CHAPTER 2. RELATED WORKS

Figure 2.2: Homepage of khambacsi.com

14


Chapter 3
Theoretical Knowledge
3.1

Front-end
Front-end web development, also known as client-side development is the


practice of producing HTML, CSS and JavaScript for a website or Web Application
so that a user can see and interact with them directly [1].

3.1.1

HTML
HTML stands for HyperText Markup Language. It is the language that

web browsers read to build a web page. It acts as a ‘blueprint’ to display data on
a user’s screen. This is the basic building block of the web. Every page on the
Internet is just HTML at its core.

15


3.2. BACK-END

3.1.2

CHAPTER 3. THEORETICAL KNOWLEDGE

CSS
CSS stands for Cascading Style Sheets which allowed developers to put

some color and style into website to make it more pleasing. The simplest way to
understand web operation is this analogy of a web page as a house, every house
need to have structure and frame, that is HTML in web page and we can not just
house with structure along, we need to some decoration into a house therefor CSS
is a crucial part of web development.


3.1.3

TypeScript
TypeScript which is a modern age JavaScript development language. JavaScript

is a scripting language which helps to create a interactive web pages and its runs
in user’s web browser whereas TypeScript is a superset of JavaScript. In order to
run on browser, TypeScript needs to compile to JavaScript file. The big difference
of TypeScript compare with JavaScript is TypeScript requires type declaration
whereas JavaScript has no such concept.

3.2

Back-end
Back-end Development is the term for the behind-the-scenes activities that

occurs when user access anything on the website or web application. It is usually
referred to the server-side development.

3.2.1

NoSQL
NoSQL databases are databases that store data in a format other than

relational tables. People can understand NoSQL stands for ”non SQL” or also

16


3.2. BACK-END


CHAPTER 3. THEORETICAL KNOWLEDGE

”not only SQL”. NoSQL makes it easier to developers to quickly adapt to changing
requirements because of its flexibility.

3.2.1.1

What is SQL?

SQL stands for Structured Query Language. SQL is used to communicate
with a database. According to ANSI (American National Standards Institute),
it is the standard language for relational database management systems. SQL
statements are used to perform tasks such as update data on a database, or retrieve
data from a database. The standard SQL commands such as ”Select”, ”Insert”,
”Update”, ”Delete”, ”Create”, and ”Drop” can be used to accomplish almost
everything that one needs to do with a database.

3.2.1.2

Types of NoSQL Databases

• Document databases: store data in documents similar to JSON objects.
Each document contains pairs of fields and values. The values can typically
be a variety of types including things like strings, numbers, booleans, arrays,
or objects, and their structures typically align with objects developers are
working with in code. Because of their variety of field value types and powerful query languages, document databases are great for a wide variety of use
cases and can be used as a general purpose database. They can horizontally
scale-out to accomodate large data volumes[2].
• Key-value databases are simpler type of database where each item contains keys and values. A value can typically only be retrieved by referencing

its key, so learning how to query for a specific key-value pair is typically
simple. Key-value databases are great for use cases where you need to store
large amounts of data but you don’t need to perform complex queries to
retrieve it. Common use cases include storing user preferences or caching
[2].
17


3.2. BACK-END

3.2.2

CHAPTER 3. THEORETICAL KNOWLEDGE

GraphQL
GraphQL is a query language for APIs and a runtime for fulfilling those

queries with existing data. GraphQL provides a complete and understandable
description of the data in API, give clients the power to ask for exactly what
they need and nothing more. make it easier to evolve API over time, and enables
powerful developer tools [3].

3.2.2.1

Fields

The fundamental of GraphQL is the way to ask for specifice fields on objects.
Here is one example:

Figure 3.1: GraphQL Example


Notice how the query has exactly the same shape as the result. This is
essential to GraphQL, because user always get back what they expect, and their
server knows exactly what fields the client is asking for. The fields name return a
String type.

3.2.2.2

Arguments

GraphQL supports the ability to pass arguments to fields make it becomes
more useful for data fetching. In the example, we pass the argument id with value
1000 and the query result will return all objects which match with that id
18