BIODATA Henra Setia Nugraha
Address : Jl. Raya Subang Dusun Kayumanis RT 12/14, Desa Sukarasa, Kec. Darma, Kab. Kuningan, Prov. Jawa Barat
Phone : +6281224099720
Email : henra.sn@gmail.com
Informasi Personal
Place & D.O.B : Kuningan, Desember 20th 1992
Marital Status : Single
Religion : Moslem
Gender Male
Languages Known : Sunda, Indonesian, English
Pendidikan Formal
Indonesia Computer University Teknik Informatika 2011 – 2016
SMAN 1 Kuningan IPA 2008 – 2011
SMPN 1 Kuningan 2005 – 2008
ANALISIS PERFORMANSI WEB SERVICE API GRAPHQL
PADA DOMAIN M-COMMERCE MENGGUNAKAN NODEJS
DAN MONGODB
SKRIPSI
Diajukan Untuk Ujian Akhir Sarjana
HENRA SETIA NUGRAHA
10111351
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK DAN ILMU KOMPUTER
UNIVERSITAS KOMPUTER INDONESIA
iii
KATA PENGANTAR
Assalamualaikum Wr.Wb.
Puji dan syukur penulis panjatkan kehadirat Allah SWT atas rahmat dan karunia-Nya sehingga penulis dapat menyelesaikan skripsi yang berjudul “Analisis Performansi Web Service Api GraphQL Pada Domain M-Commerce Menggunakan Nodejs Dan Mongodb” sebagai syarat untuk menyelesaikan program studi Strata I Jurusan Teknik Informatika Fakultas Teknik dan Ilmu Komputer pada Universitas Komputer Indonesia.
Penyusunan skripsi ini tidak akan terwujud tanpa mendapat dukungan, bantuan dan masukan dari berbagai pihak. Untuk itu, penulis ingin menyampaikan terima kasih kepada:
1. Allah SWT atas petunjuk, pertolongan, karunia, hidayah, kekuatan, kesehatan, dan kesabaran selama menyelesaikan skripsi ini. Sholawat serta salam selalu terlimpahkan kepada baginda Nabi Muhammad SAW.
2. Orang tua dan keluarga tercinta, yang senantiasa memberikan doa, semangat, motivasi, dan kasih sayangnya kepada penulis .
3. Bapak Adam Mukharil Bactiar, S.Kom., M.T. selaku dosen pembimbing yang telah sabar membimbing, memotivasi, memberikan perhatian dan memberikan pengarahan selama penelitian tugas akhir ini sehingga tugas akhir ini bisa terselesaikan dengan sebaik-baiknya.
4. Ibu Ednawati Rainarli selaku reviewer yang telah memberikan masukan dan arahan selama perbaikan analisis ini.
5. Bapak Andri Heryandi, S.T., M.T. selaku selaku penguji tiga yang telah menguji kompetensi dan memberikan masukan untuk penelitian ini.
6. Ibu Utami dewi selaku dosen wali IF-1 angkatan 2011.
7. Seluruh Dosen dan Staff pengajar jurusan Teknik Informatika Universitas Komputer Indonesia.
iv
9. Muhammad Rivki, Rosmaya Nurbayati, Arifin Bardansyah, Alfons Santoso Azhari, dan Hafizha Husnaisa yang telah mensupport dalam pengerjaan penelitian ini.
10. Teman – teman kelas IF-1 angkatan 2011 yang berjuang bersama sama kuliah. 11. Semua pihak yang terlibat dan ikut membantu dalam tugas akhir ini baik secara
langsung maupun tidak langsung.
Sangat disadari bahwa dalam pelaksanaan dan penyusunan skripsi ini masih banyak kekurangan dan jauh dari kesempurnaan. Oleh karena itu, saran dan kritik yang membangun sangat diharapkan untuk pengembangan ke arah yang lebih baik.
Bandung, 25 Agustus 2016
v
DAFTAR ISI
ABSTRAK ... i
ABSTRACT ... ii
KATA PENGANTAR ... iii
DAFTAR ISI ... v
DAFTAR GAMBAR ... viii
DAFTAR TABEL ... x
DAFTAR SIMBOL ... xii
DAFTAR LAMPIRAN ... xv
BAB 1 PENDAHULUAN ... 1
1.1 Latar Belakang Masalah... 1
1.2 Rumusan Masalah ... 2
1.3 Maksud dan Tujuan ... 3
1.4 Batasan Masalah ... 3
1.5 Metodologi Penelitian ... 3
1.6 Sistematika Penulisan ... 5
BAB 2 Landasan Teori ... 7
2.1 Web Service ... 7
2.2 Quality of Service for Web Service ... 7
2.3 GraphQL ... 12
2.4 REST ... 18
2.5 Android ... 20
2.6 BlazeMeter ... 21
2.7 Heroku cloud ... 22
vi
2.9 M-Commerce ... 23
2.10 Object Oriented Analysis And Design ... 23
2.11 Pengujian Unit ... 28
BAB 3 ANALISIS DAN PERANCANGAN SISTEM ... 29
3.1 Analisis Domain ... 29
3.1.1 Analisis Data ... 30
3.1.2 Analisis Query ... 33
3.1.3 Analisis Collections ... 35
3.2 Analisis Web Service ... 37
3.2.1 Web Service API Menggunakan REST ... 37
3.2.2 GraphQL API ... 42
BAB 4 IMPLEMENTASI DAN PENGUJIAN SISTEM ... 49
4.1 Sistem Bahan Uji ... 49
4.1.1 Lingkungan sistem... 49
4.1.2 Implementasi Data ... 50
4.1.3 Implementasi kelas ... 51
4.1.4 Implementasi Prototype ... 61
4.1.5 Dokumentasi API ... 63
4.2 Pengujian sistem ... 64
4.2.1 Rencana Pengujian ... 64
4.2.2 Scenario pengujian ... 69
4.2.3 Hasil Pengujian ... 78
4.2.4 Evaluasi Pengujian ... 90
BAB 5 kesimpulan dan saran ... 93
5.1. Kesimpulan ... 93
vii
94
DAFTAR PUSTAKA
[1] W. Siswoutomo, Membangun Web Service Open Source Menggunakan PHP, Jakarta: Elex Media Komputindo, 2004.
[2] E. C. Ortiz, “Introduction to Facebook APIs,” 10 Desember
2010. [Online]. Available:
http://www.ibm.com/developerworks/library/x-androidfacebookapi/. [Diakses 11 February 2016].
[3] P. Bela, “GraphQL in the age of REST APIs,” 7 Juli 2015. [Online]. Available: https://medium.com/chute-
engineering/GraphQL-in-the-age-of-rest-apis-b10f2bf09bba#.qbmjsrrvq. [Diakses 11 February 2016].
[4] W. N. W. A. RAHMAN dan D. F. MEZIANE, “Challenges to Describe QoS Requirements for Web Services Quality ,” vol. 5, p. 51, 2008.
[5] K. Lee, J. Jeon, W. Lee, S.-H. Jeong dan S.-W. Park, “QoS for
Web Services: Requirements and Possible Approaches,” W3C
Working Group Note 25 November 2003, [Online]. Available: http://www.w3c.or.kr/kr-office/TR/2003/ws-QoS/.
[6] T. Rajendran dan P. Dr. Balasubramanie, “Analysis on the Study of QoS-Aware Web ,” Journal of Computing, vol. 1, no. 1, p. 119, 2009.
[7] A. Mani dan A. Nagarajan, “Understanding Quality of Service for Web Services,” Improving the performance of your Web Services, 2002.
95
[9] N. Schrock, “GraphQL Introduction,” Facebook, 1 May 2015.
[Online]. Available:
https://facebook.github.io/react/blog/2015/05/01/GraphQL-introduction.html.
[10] F. Employee, “GraphQL,” Facebook, [Online]. Available: https://facebook.github.io/GraphQL/.
[11] V. Bojinov, RESTful Web API Design with Node.js, Birmingham B3 2PB: Packt Publishing Ltd, 2015.
[12] A. Hanjura, Heroku Cloud Application Development, Birmingham: Packt Publishing, 2014.
[13] “Introducing JSON,” [Online]. Available: http://www.json.org/.
[14] H. Divayana, Konsep OOAD, Jakarta: STMIK Eresha, 2010. [15] J. Hermawan, Analisa Desain & Pemrograman Berorientasi Objek dengan UML dan Visual Basic.NET, Yogyakarta: Andi, 2010. [16] K. Hamilton dan R. Miles, Learning UML 2.0, United States
of America: O'Reilly, 2006.
[17] R. Osherove, The Art of Unit Testing Second Edition, Shelter Island: Manning Publications Co, 2014.
[18] F. Doglio, Pro REST API Development with Node.js, La Paz, Canelones: Apress, 2015.
[19] I. P. A. E. Pratama, E-commerce, E-Business, Mobile Commerce, Bandung: BI-Obses, 2015.
[20] Susila dan S. Vadivel, “QoS Measurement Tool for Web Service Selection,” International Journal of Web Engineering, vol. 3,
1
BAB 1
PENDAHULUAN
1.1Latar Belakang Masalah
Aplikasi Web saat ini berkembang pesat mulai dari front-end hingga back-end, dan teknologi Web ini mendukung perkembangan teknologi komputasi terdistribusi (distributed computing) dimana teknologi ini memungkinkan melakukan proses di banyak mesin, dan hasilnya dimanfaatkan oleh banyak mesin. Salah satu dukungan teknologi Web pada komputasi terdistribusi adalah pada pembangunan Web Service yang berfungsi sebagai aplikasi transaksi data antar mesin yang terlibat di dalamnya. Konsep Web Service muncul untuk menjembatani sistem-sistem informasi yang ada tanpa mempermasalahkan perbedaan platform yang digunakan oleh masing-masing sumber [1]. Dalam pembangunan Web Service ada beberapa teknologi yang dapat digunakan di antaranya SOAP, RESTful,
dan RPC-XML. Selain teknologi tersebut terdapat satu teknologi Web Service yakni GraphQL, yang diciptakan dan digunakan oleh perusahaan Facebook ini mengubah
paradigma membaca dan menulis data berorientasi fungsi menjadi berorientasi objek. Beberapa contoh objek dari facebook di antaranya adalah users, photos, albums, dan koneksi/friendlist. Pendekatan ini membuat Facebook api lebih
sederhana dan konsisten saat bekerja dengan objek [2].
RESTful merupakan salah satu dari arsitektur-style Web Service yang
tergolong teknologi lama dan mudah untuk dipahami saat membangunnya. Namun pada tahun 2015 teknologi baru yang diciptakan oleh perusahaan ternama yang membidangi social media Facebook yakni GraphQL. Teknologi GraphQL ini merupakan teknologi open source sehingga pengembang yang lain dapat ikut mengembangkan teknologi ini. Saat ini satu-satunya kasus penggunaan produksi GraphQL adalah Facebook. GraphQL berfungsi dengan baik untuk jejaring sosial
Facebook tetapi masih belum bisa dipastikan akan berfungsi baik pada sistem yang
2
Facebook memindahkan beberapa api dari RESTful api ke graph api. Facebook
memindahkan beberapa api ke graph api bukan tanpa alasan. Selain itu ada beberapa penulis di situs medium.com menyatakan bahwa RESTful sudah layak untuk digantikan oleh GraphQL dengan beberapa alasan, namun dari alasan yang mereka tulis pada situs tersebut belum ditemukan artikel yang membahas mengenai QoS(Quality of Service) Web Service pada GraphQL. Menurut hipotesa sementara
ada beberapa kekurangan pada teknologi RESTful, dan kekurangan tersebut dapat diselesaikan menggunakan teknologi GraphQL api. Namun teknologi GraphQL ini tergolong teknologi yang masih baru, belum ada pengujian secara khusus terhadap teknologi ini.
Berdasarkan pemaparan permasalahan tersebut, didapatkan solusi yaitu dengan membangun sebuah Web Service GraphQL untuk melakukan pengujian performansi dan membandingkannya dengan Web Service yang menggunakan RESTful. Salah satu objek yang dapat dijadikan sebagai sampel pengujian adalah
Web Service untuk m-commerce, karena perkembangan pada m-commerce sangat
cepat, dapat dilihat hadirnya beberapa m-commerce di Indonesia seperti lazada, blibli, zalora, zoya, berrybenka, shopee, bhinneka.com, matahari mall, dan bukalapak, sehingga hasil dari penelitian ini akan sangat berguna untuk beberapa developer dalam mempertimbangkan migrasi Web Service api dari teknologi sebelumnya ke teknologi GraphQL. Selain itu aspek yang dapat dijadikan sebagai parameter ukur untuk perbandingan antara GraphQL dengan RESTful yakni QoS Web Service.
1.2Rumusan Masalah
3
1.3Maksud dan Tujuan
Maksud dari penelitian ini adalah menguji performansi dari teknologi GraphQL pada domain selain sosial media yakni m-commerce. Adapun tujuan dari
penelitian ini adalah untuk melihat kualitas performance dari teknologi GraphQL, sehingga dapat membantu developer Web Service api dalam mempertimbangkan migrasi dari teknologi REST ke GraphQL. Dan membandingkannya menggunakan aspek QoS Web Service sebagai parameter ukur.
1.4Batasan Masalah
Adapun batasan masalah yang digunakan dalam penelitian ini adalah sebagai berikut:
1. Dalam penelitian ini pembentukan query atau request data hanya yang berkaitan dengan data produk.
2. Dalam penelitian ini melibatkan mobile device sebagai salah satu alat untuk menguji request dan response dari server, mobile device menggunakan sistem operasi android 4.4.4.
3. Untuk representasi data yang akan dijadikan sebagai pesan antara client-server menggunakan format JSON.
4. Acuan pembanding antara RESTful dengan GraphQL menggunakan karakteristik QoS yang sering digunakan [4] yakni Service time, reliability, execution price, availability, performance , dan security, namun pada penelitian
ini security dan execution price tidak digunakan.
1.5Metodologi Penelitian
4
Gambar 1-1 Alur Penelitian
Berikut penjelasan dari setiap tahapan dalam penelitian. 1. Analisis Domain
Pada subbab ini akan dibahas mengenai beberapa hal mengenai masalah yang terjadi pada domain kasus m-commerce, mulai dari permasalahan dari segi mobile hingga commercenya itu sendiri.
2. Analisis Fitur
Pada subbab ini akan dijelaskan beberapa fitur yang terdapat di dalam aplikasi m-commerce, tidak hanya fitur yang dianalisis namun data yang digunakan pada setiap fiturpun akan dibahas. Analisis fitur ini bermaksud untuk mencari data apa saja yang sering digunakan pada aplikasi m-commerce, setelah didapat data yang sering digunakan, maka data tersebut akan digunakan sebagai objek . . . 3. Analisis Data
Berdasarkan hasil analisis fitur terdapat data yang sering diakses dalam m-commerce, data tersebut akan dianalisis mulai dari bentuk
4. Analisis Query
Analisis Domain Analisis Fitur Analisis Data
Analisis Query Analisis GraphQL API
Analisis RESTful API
5
Pada subbab ini akan dilakukan analisis yang hampir sama dengan analisis fitur namun perbedaannya terletak pada hasil dari analisis, target dari analisis ini adalah dapat melihat bentuk query atau request data yang ada di dalam setiap fitur, query yang terbentuk akan dijadikan sebagai bahan uji pada bab pengujian.
5. Analisis GraphQL API
Pada subbab ini akan dijelaskan mengenai cara kerja dari GraphQL API menggunakan sample.
6. Analisis RESTful API
Pada tahap ini akan dilakukan analisis cara kerja dari teknologi RESTful API dengan menggunakan sample.
7. Pengujian
Pengujian merupakan poin utama di mana penelitian mengenai analisis performansi GraphQL dapat terlihat jelas, pada subbab ini akan dibahas mengenai
langkah-langkah pengujian Web Service api GraphQL dan RESTful. Setiap poin dari QoS Web Service memiliki cara untuk menguji yang berbeda-beda, pada subbab ini akan dibahas bagaimana cara pengujian pada setiap poin pada QoS Web Service.
1.6Sistematika Penulisan
Sistematika penulisan tugas akhir ini disusun untuk memberikan gambaran umum mengenai penelitian yang dikerjakan. Sistematika penulisan dalam dokumentasi skripsi ini adalah sebagai berikut:
BAB 1 PENDAHULUAN
6
BAB 2 LANDASAN TEORI
Bab 2 menguraikan bahan-bahan kajian, konsep dasar, dan teori dari para ahli yang berkaitan dengan penelitian. Meninjau permasalahan dan hal-hal yang berguna dari penelitian-penelitian dan sintesis serupa yang pernah dikerjakan sebelumnya dan menggunakannya sebagai acuan pemecahan masalah pada penelitian ini.
BAB 3 ANALISIS
Bab 3 menguraikan hasil analisis dari objek penelitian untuk mengetahui hal atau masalah apa yang timbul dan mencoba memecahkan masalah tersebut dengan mengaplikasikan perangkat-perangkat dan pemodelan yang digunakan.
BAB 4 PENGUJIAN SISTEM
Bab 4 menguraikan tentang perancangan solusi beserta implementasinya dari masalah-masalah yang telah dianalisis. Pada bagian ini juga akan ditentukan bagaimana sistem dirancang, dibangun, diuji dan disesuaikan dengan hasil penelitian.
BAB 5 KESIMPULAN DAN SARAN
7
BAB 2
LANDASAN TEORI 2.1Web Service
Web Service merupakan salah satu komponen sistem terdistribusi pada SOA
(Service Oriented Architecture). Service dibangun untuk menyediakan interface yang memproses dan mengirim pesan dalam bentuk xml atau json. Service menggunakan object oriented untuk mendefinisikan pesan yang akan dikirim kepada client atau Service yang lain. Selain menyediakan interface untuk menerima dan mengirim pesan dari client atau Service lain melalui protokol (HTTP, SMTP, TCP), Service juga menangani beberapa business logic dan beberapa operasi CRUD
di dalamnya.
2.2Quality of Service for Web Service
Untuk membangun sebuah sistem informasi yang berukuran kecil hingga besar diperlukan sebuah standarisasi dan mekanisme, sehingga sistem yang dibangun memiliki kualitas yang baik, selain itu mudah untuk maintenance. Untuk membangun sebuah sistem informasi Web Service ada beberapa standar yang harus diperhatikan di antaranya. [5]
1. Performance
8
Pengukuran performance pada QoS Web Service lebih fokus pada pengukuran throughput, response time, dan latency [6] [7] [8]. Throughput merepresentasikan permintaan/satuan waktu, dimana throughput ini mengukur seberapa banyak request yang ditangani atau di-handle oleh server secara periodik. Response time mengukur berapa lama server mengirimkan data kepada client. Latency mengukur waktu delay antara waktu client melakukan request dan waktu ketika client mendapatkan response dari server.
Gambar 2-1 Client Server Transaction
1. Throughput
Pengukuran throughput dapat dilakukan dengan cara melakukan lebih dari satu request dalam kurun waktu tertentu dan dalam dilakukan secara bersamaan. Untuk mendapatkan nilai maksimal throughput dapat menggunakan rumus sebagai berikut:
Proses pengukuran nilai maksimal throughput dapat dilakukan dengan melakukan logging atau pencatatan jumlah request yang di-handle oleh server dalam kurun waktu tertentu.
Maksimal throughput = �ℎ � � � ��
9
2. Latency
Pengukuran waktu latency merupakan waktu delay dimana client menunggu response yang diberikan oleh server. Untuk mendapatkan nilai waktu delay dapat menggunakan rumus sebagai berikut:
Pengukuran latency dapat dilakukan dengan cara melakukakan logging atau pencatatan pada client, yang dapat dicatat adalah waktu ketika client melakukan request ke server dan waktu ketika client mendapatkan response dari sever. Setelah waktu tersebut didapatkan, maka rumus diatas dapat digunakan untuk mendapatkan nilai latency.
3. Response Time
Pada pengukuran ini merupakan perhitungan waktu yang diperlukan untuk menyelesaikan request. Waktu yang dihitung adalah waktu dimana server melakukan execution time dan memberikan response kepada client. Untuk mendapatkan nilai response time dapat menggunakan rumus sebagai berikut:
Data transfer time merupakan waktu dimana server mengirimkan data json ke client. Pengukuran ini juga dapat menggunakan logging atau pencatatan, waktu yang dicatat adalah waktu yang diperlukan untuk business logic yang didapat dari waktu ketika server mendapatkan request hingga business logic selesai dilakukan, dan waktu yang diperlukan untuk mengirim data ke client yang didapat dari waktu business logic selesai dilakukan hingga data tersebut sampai di client.
Parameter qualitas performance pada Web Service dapat dilihat dari empat point yang telah dijabarkan sebelumnya yakni throughput, response time, latency
Latency = response time – request time ... persamaan(2.2)
10
dan execution time. Web Service yang memiliki performance yang baik dapat diliha dari throughput yang cepat, latency yang rendah, response yang cepat, dan execution cepat.
2. Reliability
Reliability merupakan tolak ukur untuk tingkat maintain Web Service. Mengukur tingkat kegagalan pada sistem setiap hari, minggu, bulan, atau tahun tergantung dari seberapa besar kemampuan pengembang untuk melakukan maintain. Karena tidak ada jaminan semua pesan atau response akan sampai ke tujuan.
3. Scalability
Dalam pembangunan sebuah sistem akan dimulai dari prototype di mana sistem belum siap untuk digunakan secara utuh, karena beberapa fungsi masih memiliki error atau bug. Setelah semuanya fungsional dapat dijalankan sesuai dengan harapan developer tidak akan berhenti untuk mengembangkan lagi sistem yang telah dibangun, oleh karena itu sistem sangat dituntut untuk dapat dikembangkan menjadi sistem yang sesuai dengan kebutuhan saat itu. Misalnya dalam meningkatkan kemampuan sistem dalam memproses setiap request dari user yang semakin meningkat jumlahnya.
4. Capacity
Web Service saat ini salah satu distributed system yang sering digunakan untuk transaksi data, client atau system yang menggunakan layanan dari Web Service tersebut bermacam-macam dari Web , desktop application, hingga mobile.
Pada kasus m-commerce saat ini sudah banyak aplikasi yang menyediakan layanan untuk membeli barang secara online atau pengguna dapat menjadi penjual untuk pengguna lainnya. Pengguna pada aplikasi lazada telah mencapai lebih dari sepuluh juta download, dengan demikian Web Service lazada harus mampu untuk meng-handle request dari pengguna yang begitu banyak dalam waktu yang bersamaan.
11
Request client yang memiliki parameter untuk diproses di dalam server
yang terkadang ada beberapa parameter tidak memiliki nilai yang berakibat kesalahan pada sistem yang dikarenakan human error dari pengguna atau validasi pada sistem masih kurang dan sistem Web Service dituntut untuk dapat menangani masalah tersebut.
6. Exception Handling
Dalam pembangunan sistem memungkinkan beberapa hal yang tidak terprediksi dapat terjadi. Contoh sederhana dalam hal request, client akan melakukan request ke server dengan beberapa parameter, namun tidak semua parameter bersifat required, maka server harus mampu untuk menanggulangi jika ada parameter yang tidak bersifat required tidak memiliki nilai.
7. Accuracy
Akurasi merupakan hal penting dalam sistem informasi, namun di sini maksud dari akurasi adalah tingkat kesalahan yang dihasilkan oleh layanan Web . 8. Integrity
Integrity salah satu hal yang wajib ada di dalam Web Service untuk
mencegah unauthorized access atau modifikasi pada sistem atau data. Ada dua tipe integrity yakni data integrity dan transactional integrity. Data integrity memastikan
apakah data yang di transfer telah dimodifikasi ketika transit. Sedangkan transactional integrity mengacu pada prosedur yang menjamin menjaga database
integrity dalam transaksi.
9. Accessibility
Client dari Web Service tidak hanya satu jenis, ada beberapa jenis client
yakni mobile, desktop, maupun Service lainnya. Jadi Web Service harus mampu untuk melayani setiap request yang berbeda-beda.
12
Pembangunan Web Service api tidak semata-mata dibangun dari awal sebuah startup atau perusahaan dari awal, terkadang pembangunan Web Service dibangun di tengah jalan dengan alasan permintaan dari pengguna atau ekspansi dari perusahaan itu sendiri ataupun rencana untuk membangun sistem terintegrasi. Maka dari itu Web Service harus mampu tersedia sesegera mungkin untuk berbagai keperluan dalam integrase ataupun ekspansi.
11.Interoperability
Dalam pembangunan sebuah sistem informasi khususnya Web Service tidak hanya memikirkan masalah bahasa pemrograman yang digunakan namun ada beberapa hal seperti sistem dari database. Tidak hanya itu developer juga harus memikirkan bagaimana untuk menggunakan sistem dari database di dalam Web Service yang dibangun. Selain database ada juga sistem lain yakni jalur komunikasi
seperti http protocol. Jadi Web Service harus memiliki kemampuan untuk berinteraksi dengan sistem lain tanpa akses yang rumit.
12.Security
Salah satu media sosial dunia yakni facebook memiliki jutaan data pribadi mengenai penggunanya di seluruh dunia. Data tersebut bersifat rahasia, tidak sembarang orang atau kelompok dapat mengakses data tersebut. Sehingga perusahaan facebook harus mampu untuk menjaga semua data dari setiap penggunanya. Kini facebook telah menyediakan Service untuk perusahaan atau aplikasi lain agar dapat mengakses akun tertentu dengan beberapa kebijakan dari facebook untuk menjaga data pengguna agar tidak semua data dapat diambil begitu
saja. Maka dari itu Web Service yang dibangun harus memiliki sistem keamanan seperti authentication, authorization, confidentiality, traceability and auditability, data encryption, non-repudation.
2.3GraphQL
GraphQL maupun REST tidak terpaku pada database yang digunakan, pada
13
di proyeksikan ke dalam bentuk API. Prinsip-prinsip yang digunakan GraphQL untuk membuat suatu interface atau API sebagai berikut: [9]
1. Hierarchical
GraphQL menggunakan hierarki untuk relasi antar objek, seperti halnya
dalamREST menggunakan join statement pada SQL. 2. Client Specified Queries
Pada GraphQL setiap client request untuk data fetching atau data manupulate menggunakan query yang di dalamnya berisi model data yang
dibutuhkan, berbeda dengan REST, semuanya ketentuan data yang akan disajikan dalam API sudah ditentukan, karena konsep everything is resource pada REST. 3. Backward Compabilities
Setiap mobile application minimal dalam tiga bulan akan diperbaharui, pada kasus ini setiap melakukan request data ada kemungkinan berbeda-beda setiap client, karena tidak semua client akan memperbaharui aplikasinya. sehingga
GraphQL dari itu setiap melakukan requent data ke GraphQL menggunakan
specified query bukan resource.
4. Strongly Typed
Ketika client mengirim request dengan query, setiap item yang ada di dalam objek query akan di cek satu per satu apakah data yang di-request tersedia atau tidak, jika tidak tersedia maka GraphQL akan membuat pesan error sebelum query di eksekusi.
GraphQL dibangun dalam waktu yang cukup lama, karena pembangunan
GraphQL ini diharapkan dapat menyelesaikan beberapa permasalahan pada kasus
14
Teknologi GraphQL memiliki dua buah operasi yang akan digunakan sebagai alat untuk transaksi data client-server yakni query dan mutation, query hanya digunakan untuk fetching data sedangkan mutation digunakan untuk modifikasi data.
2. Selection Set
Selection set merupakan sebuah set informasi yang dibutuhkan oleh client,
dalam selection set dapat berisi Field, FragmentSpread, atau InlineFragment. Dan client akan mendapatkan data yang sama persis dengan selection set yang dikirim
ke server. Berikut contoh bentuk dari selection set.
Gambar 2-2 Selection Set
3. Field
Sebuah selection set terbentuk dari satu atau beberapa field. Sebuah field menjelaskan satu informasi. Kumpulan field dalam satu selection set menjelaskan data yang kompleks atau keterhubungan dengan data yang lain. Untuk mendapatkan data yang lebih kompleks dalam data, memungkinkan dalam sebuah field berisi selection set. Semua operasi pada GraphQL harus menentukan selections pada field
yang mengembalikan nilai scalar untuk memastikan response yang didapat jelas. {
id
15
Gambar 2-3 Field
Field di level pertama pada selection set menandakan informasi yang dapat
diakses secara global dari client dan informasi tersebut merupakan informasi client utama atau current viewer.
4. Arguments
Secara konsep field merupakan sebuah functions yang mengembalikan nilai, dan dalam beberapa kasus field menerima argument yang dapat mengubah nilai dari hasil request. Sebagai contoh client akan me-request data user dengan id 4 dengan spesifikasi profile picture dengan ukuran 100 x 100,
16
Secara default objek dari response akan menggunakan nama field. Namun nama field yang digunakan juga diganti dengan nama alias sesuai dengan kebutuhan, nama alias digunakan untuk mempermudah dalam pembacaan data response dan menghindari duplikat key. Berikut contoh dari penggunaan alias.
Gambar 2-5 Field Alias
Dari objek request tersebut maka response dari server akan berbentuk seperti berikut.
Gambar 2-6 Result Field Alias
6. Fragments
Fragment merupakan unit utama dalam komposisi GraphQL. Fragment
memungkinkan untuk menggunakan selections berulang kali pada sebuah field. Inline fragment dapat digunakan di dalam selection . . .
{
user(id: 4) { id
name
smallPic: profilePic(size: 64) bigPic: profilePic(size: 1024) }
}
{
"user": { "id": 4,
"name": "Mark Zuckerberg",
"smallPic": "https://cdn.site.io/pic-4-64.jpg", "bigPic": "https://cdn.site.io/pic-4-1024.jpg" }
17
Gambar 2-7 Without Fragment
Selection set friends dan mutualFriend memiliki field yang sama, maka
selection set ini dapat dimasukkan ke dalam sebuah fragment.
Gambar 2-8 With Fragment
Memakai fragment menggunakan operator ( . . . ). Semua field yang berada di dalam fragment akan dimasukkan ke dalam field query yang menggunakan fragment. Fragment juga dapat diaplikasikan pada multiple levels fragment, berikut
contoh dari multiple level.
fragment friendFields on User { id
name
18
Gambar 2-9 Profile Picture Fragment
2.4REST
REST mendefinisikan satu set prinsip arsitektur di mana dapat digunakan untuk mendisain Web Service yang berfokus pada resource sistem, termasuk bagaimana resource memiliki alamat (URL address) dan dapat dikirim kepada client yang memiliki bahasa yang berbeda-beda. Interaksi antara client dengan
server menggunakan interface yang bisa diakses oleh protokol http yang sering
disebut sebagai API (Application Programming Interface). Dikarenakan pembangunan Service untuk interaksi atau manipulasi data menggunakan bahasa native dari SQL database yaitu insert, select, update, delete, maka verb yang
digunakan ada empat di antaranya post, get, put, dan delete. Dalam pembangunan RESTful Web Service api's ada beberapa prinsip yang digunakan, di antaranya: [11]
1. Each resource is identifiable by a unique
Jumlah resource pada suatu sistem lebih dari satu, dan untuk mengakses
fragment friendFields on User { id
name
. . .standardProfilePic }
fragment standardProfilePic on User { profilePic(size: 50)
19
dengan nomor ktp, satu sama lain harus berbeda untuk mengidentifikasi pemilik dari nomor ktp tersebut.
2. User the standard HTTP methods
Http protocol memiliki delapan verb yaitu sebagai berikut:
1. GET
Pada teknologi RESTful ini tidak semua verb HTTP digunakan, hanya empat yang digunakan di antaranya
Tabel 2-1 Verb RESTful
HTTP Verb Action Kode status respon
GET Request terhadap
resource yang sudah ada
“200 OK”, jika resource tersedia, “404 Not
Found”, jika resource tidak tersedia, dan “500
Intenal Server Error”, jika terdapat kesalahan di dalam server.
PUT Memasukan data atau
memperbaharui data
“201 CREATED”, jika data telah masuk ke dalam
database, “200 OK”, jika data telah diperbaharui,
“500 Intenal Server Error”, jika terdapat kesalahan di dalam server.
POST Memperbaharui data “200 OK”, jika data telah diperbaharui, “500
Intenal Server Error”, jika terdapat kesalahan di dalam server.
DELETE Menghapus data “200 OK”, jika resource terhapus, “404 Not
20
3. Resource can have multiple representations
REST dapat mendukung beberapa format data representasi tergantung pada
request yang dilakukan, selama server mendukung format tersebut.
2.5Android
Android merupakan sebuah sistem operasi yang berjalan dia atas linux
karnel, sistem operasi ini diterapkan pada mobile device seperti smartphone, komputer tablet, dan smartwatch, tidak hanya mobile device android telah digunakan pada kendaraan roda empat dan television. Android pertama kali dikembangkan oleh Android Inc., dan pada tahun 2005 Google membeli dan mengembangkannya hingga saat ini.
Android memiliki paradigma pemrograman yang berbeda dengan
pemrograman pada umumnya dimana dalam pemrograman java, method yang pertama kali dijalankan adalah main(), sedangkan pada android menjalankan kode dalam method Activity dengan menerapkan callback tertentu yang sesuai dengan tahap tertentu dari siklus hidup. siklus hidup berguna untuk memastikan aplikasi
tidak menghabiskan sumber daya baterai.
Gambar 2-10 Android Lifecycle
21
1. Created
Sebuah aplikasi pertama kali dijalankan dan mengeksekusi method onCreate() termasuk menginisialisasi komponen tampilan.
2. Started
State ini secara langsung akan diakses setelah onCreate() dijalankan, dan ketika aplikasi dijalankan setelah aplikasi tersebut di tutup.
3. Resumed
State resumed akan dijalankan setelah state paused. state ini akan menjalankan perintah yang ada di dalam method onResume()..
4. Paused
Pada state ini semua aktivitas dalam aplikasi akan dihentikan sementara. state ini berjalan ketika ada aplikasi yang berjalan dengan prioritas lebih tinggi. aplikasi tidak bisa menerima input dari user dan tidak bisa mengeksekusi
Aplikasi benar - benar mati, tidak ada proses apapun yang berjalan termasuk background Service.
2.6BlazeMeter
22
akan digunakan untuk mengakses Service api, jumlah iteration untuk request, waktu yang digunakan untuk menguji Web Service api, dan jumlah waktu delay antar requet untuk satu user virtual. Hasil pengujian disajikan dengan grafik dan data numerik untuk setiap mengujian secara detail.
2.7Heroku cloud
Heroku merupakan salah satu penyedia platform-as-a-Service (PaaS) terkemuka di bisnis cloud software, yang membuktikan dirinya sebagai solusi PaaS terkemuka untuk perusahaan kecil dan besar. Dengan peningkatan yang konsisten dan filosofinya kenyamanan melebihi konfigurasi, menjadikan developer untuk fokus dalam menulis aplikasi Web . Hal yang bersangkutan dengan server, building, deploying, running, dan scaling aplikasi akan diatasi oleh Heroku.
Heroku menyediakan dukungan platform untuk Ruby, Ruby on Rails, Java, Node.js, Clojure, Scala, Python, dan PHP. Arsitektur Heroku add-on memungkinkan developer menyesuaikan penggunaan berbagai paket pihak ketiga berdasarkan kebutuhan. Developer memiliki fleksibilitas untuk memilih plan basic atau premium berdasarkan kebutuhan Web site. Developer juga bisa mempercepat aplikasi dengan menambahkan resources seperti memcached untuk caching data, sehingga menciptakan aplikasi yang powerful yang kaya dengan fitur [12].
2.8JSON
23
2.9M-Commerce
Perkembangan dalam bidang penjualan semakin meningkat sejak hadirnya penjualan online atau dapat disebut sebagai e-commerce. Banyak kalangan memulai usaha dengan mengandalalkan e-commerce, karena tidak perlu membeli atau menyewa bangunan untuk sebuah toko, cukup dengan membuat sistem penjualan online atau e-commerce penjual cukup diam di rumah dan sediakan satu ruangan sebagai gudang. E-comnmerce memiliki beberapa jenis berdasarkan peran di dalamnya, yaitu B2B (Business to Business), B2C (Business to Client), C2C (Clinet to Client).
2.10 Object Oriented Analysis And Design
Analisis dan desain berorientasi objek adalah cara baru dalam memikirkan satu masalah dengan menggunakan model yang dibuat menurut konsep sekitar dunia nyata. Tujuan dari analisis berorientasi objek adalah untuk mengembangkan model yang menggambarkan perangkat lunak komputer karena bekerja untuk memenuhi seperangkat persyaratan yang ditentukan usir [14]. Tools yang dapat digunakan pada pendekatan analisis pengembangan sistem secara objek yaitu menggunakan UML.
Unified Modelling Language (UML) adalah sebuah bahasa yang telah
menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menggunakan class dan operation object dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak
dalam bahasa bahasa berorientasi objek [15]. Dalam membangun block UML ada tiga hal yang harus diperhatikan, yaitu object (memodelkan konsep), relationship (menghubungkan object), dan diagram (grouping yang saling menghubungkan antara object dan relationship. Diagram yang umum dipakai dalam analisis dan desain adalah:
1. Use Case Diagram
Use Case Diagram menggambarkan fungsionalitas yang diharapkan dari
24
dengan sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang serupa. Sebuah use case juga dapat meng-extend usecase lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Dasar menentukan sebuah use case adalah use case merupakan sesuatu yang menyediakan beberapa hasil terukur kepada pengguna atau sistem eksternal. Use case harus memiliki sangat jelas kriteria lulus / gagal. Pengembang, tester, penulis
teknis, dan pengguna harus secara eksplisit tahu apakah sistem memenuhi kasus penggunaan atau tidak. Setiap bagian dari use case yang memenuhi tes sederhana ini mungkin menjadi kandidat yang baik untuk use Chase. Dasar pembangunan use case diagram dapat dilihat pada Gambar 2-11 Dasar Pembangunan Use Case
Diagram.
Gambar 2-11 Dasar Pembangunan Use Case Diagram
2. Use Case Scenario
25
format penulisan use case scenario [16]. Dasar pembangunan use case scenario dapat dilihat pada Error! Reference source not found..
Tabel 2-2 Dasar Pembangunan Use Case Scenario
Use Case Name Berisi nama dari use case yang akan digunakan Goal In Context Menjelaskan apa yang aktor coba untuk dapatkan
dari use case
Description Menjelaskan gambaran dari use case
Related Use Case Daftar use case yang berhubungan dengan use case
tersebut
Successful End
Condition
Kondisi use case jika berhasil
Failed End Condition Kondisi use case jika gagal
Actors Daftar aktor yang dapat mengakses use case
Trigger Aktifitas yang dilakukan untuk mengawali use case
Main Flow Step Action
1 Deskripsi urutan aksi dari aktifitas use case
2
Extension Step Branching Action
2.1 Deskripsi urutan aksi lain selain urutan aksi utama
3. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek
yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali
26
Gambar 2-12 Dasar Pembangunan Sequence Diagram
4. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) satu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class memiliki tiga area pokok:
a. Nama dan stereotype b. Atribut
c. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut: a. Private, tidak dapat dipanggil dari luar class yang bersangkutan.
b. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.
c. Public, dapat dipanggil oleh siapa saja.
27
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.
Class memiliki tipe-tipe relationship, diantaranya:
a. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain.
b. Agregasi, yaitu hubungan yang menyatakan bagian terdiri atas dimana ketika satu class di share atau direferensikan kepada objek yang ada di class lain. c. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari
class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
d. Komposisi, yaitu jenis relasi class diagram yang kuat dimana jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.
e. Depedensi, salah satu jenis relasi class diagram yang lemah dimana objek dalam suatu class akan bekerja sangat singkat dengan objek yang ada pada class lain.
Gambar 2-13 Dasar Pembangunan Class Diagram
28
Activity diagram menggambarkan berbagai alur aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing aliran berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Sebuah aktivitas dapat direalisasikan oleh satu usecase atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara usecase menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk
mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu [15].
2.11 Pengujian Unit
Pengujian unit merupakan pengujian yang menguji bagian terkecil dari kode, biasanya fungsi individu, sendirian, dan terisolasi. Ketika pengujian menggunakan beberapa sumber daya eksternal, seperti database, hal ini bukanlah pengujian unit.
93
BAB 5
KESIMPULAN DAN SARAN
5.1. Kesimpulan
Dari hasil pengujian, maka dapat diperoleh kesimpulan bahwa pengujian performance dengan empat tahap pengujian dan memiliki spesifikasi yang berbeda
sistem REST masih lebih unggul dari GraphQL. Untuk pengujian prototype menggunakan android mobile device menggunakan teknik multithreading, hasil yang didapat adalah waktu delay GraphQL lebih lama dari REST, sehingga dapat disimpulkan untuk pnegujian ini GraphQL masih belum lebih baik dari sisi waktu delay.
5.2.Saran
Penelitian ini menggunakan QoS sebagai acuan pembanding antara sistem yang menggunakan rest dan sistem yang menggunakan GraphQL, terdapat tiga belas point yang dapat dijadikan sebagai pembanding namun pada penelitian ini hanya menggunakan poin performansi. Adapun saran – saran untuk peneliti yang mengambil masalah yang sama dengan penelitian ini adalah sebagai berikut: 1. Poin pengujian ditambah, sesuai dengan QoS untuk membuktikan dari segi
yang lain
