JCSI 16 (2020) 309–316

Received: 13 July 2020

Accepted:29 August 2020

Comparison of REST and GraphQL web technology performance

Porównanie wydajności technologii webowych REST i GraphQL
Mateusz Mikuła*, Mariusz Dzieńkowski
Department of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
Abstract
The aim of the study was to compare the performance of two data exchange styles commonly used in web applications,
i.e. REST and GraphQL. For the purposes of the study two test applications were developed containing the same func-
tionalities, one of which was REST and the other one was GraphQL. They were used for performance tests done with
the help of the JMeter tool, during which measurements of the total processing time of requests and the volume of data
downloaded and sent were performed. An experiment was developed that tested the basic operations found in most
network services: display, add, update, and delete data. The most attention was devoted to the information display oper-
ation in the case of which load tests were done. On the basis of performed studies and obtained results, no differences in
performance during the operation of adding, editing and deleting data by applications based on REST API and
GraphQL were found. During the display operation under heavy load conditions and while downloading small portions
of data, the service using GraphQL had a better performance. When downloading large portions of data, the REST-
based service exhibited a higher performance.
Keywords: REST; GraphQL; web service; performance testing
Streszczenie
Zrealizowano badania, których celem było porównanie wydajności dwóch, szeroko stosowanych w aplikacjach webo-
wych stylów wymiany danych REST i GraphQL. Na potrzeby badań opracowano dwie usługi testowe, zawierające te
same funkcjonalności, z których jedna była serwisem REST, a druga GraphQL. Posłużyły one do testów wydajnościo-
wych, przeprowadzonych za pomocą narzędzia JMeter, podczas których wykonywano pomiary całkowitego czasu prze-
tworzenia żądań oraz wielkości pobieranych i wysyłanych danych. Opracowano eksperyment, w ramach którego testo-
wano podstawowe operacje występujące w większości usług sieciowych: wyświetlanie, dodawanie, aktualizowanie oraz
usuwanie danych. Najwięcej uwagi poświęcono operacji wyświetlania informacji, w przypadku której wykonano testy
obciążeniowe. Na podstawie zrealizowanych badań i uzyskanych wyników nie stwierdzono różnic w wydajności pod-
czas realizacji operacji dodawania, edycji i usuwania danych przez aplikacje oparte na REST API i GraphQL. Podczas
operacji wyświetlania w warunkach dużego obciążenia i w przypadku pobierania małych porcji danych lepszą wydaj-
ność miała usługa wykorzystująca GraphQL. Natomiast w przypadku pobierania dużych porcji danych wyższą wydaj-
ność uzyskiwała usługa oparta na REST.
Słowa kluczowe: REST; GraphQL; usługa internetowa; testowanie wydajności
*
Corresponding author
Email address: [email protected] (M. Mikuła)
©Published under Creative Common License (CC BY-SA v4.0)

1. Wstęp nych informacji [2]. Pomimo wielu zalet i to rozwiąza-

nie ma swoje ograniczenia, które ujawniły się w przy-
1.1. Style wymiany danych REST i GraphQL
padku popularnych w ostatnim czasie serwisów spo-
Aplikacje webowe są obecnie szeroko stosowane ze łecznościowych, w których korzystanie z REST okazało
względu na popularność Internetu. Działają one w prze- się uciążliwe ze względu na nieakceptowalny przez
glądarce internetowej przez co wielu użytkowników użytkowników, długi czas wczytywania się wyświetla-
może jednocześnie z nich korzystać. Aplikacje webowe nych postów na urządzeniach mobilnych [3]. Rozwią-
komunikują się z usługami sieciowymi poprzez różne zaniem tej kwestii zajęli się programiści firmy Facebo-
interfejsy programistyczne (API) za pomocą żądań ok i w 2018 roku opublikowali pierwszą wersję języka
i odpowiedzi używając do tego celu różnych protoko- zapytań dla interfejsów API o nazwie GraphQL, do
łów (HTTP, FTP, POP3, itd.). Do tej pory opracowano komunikowania się z serwerem [4].
wiele standardów, które określają sposób komunikacji Wybór stylu wymiany danych dla tworzonej aplika-
klienta z serwerem. Na początku były to protokoły takie cji, ma istotne znaczenie w kontekście czasu dostarcza-
jak RPC, COBRA, SOAP, które były złożone, a przez nia danych. Im więcej informacji aplikacja jest w stanie
to trudne w użyciu. Problemy te zostały wyeliminowane przetworzyć w określonym przedziale czasu, tym jest
przez powstały w 2000 roku styl architektoniczny REST ona bardziej wydajna. Należy pamiętać, że wydajność
(Representational State Transfer) [1], który jest skalo- to jeden z najważniejszych aspektów powodzenia funk-
walnym, prostym, rozszerzalnym i zoptymalizowanym cjonowania rozwiązania w świecie rzeczywistym [5].
wzorcem architektury określającym format przesyła- Dotyczy to szczególnie aplikacji internetowych, dają-
cych możliwość jednoczesnego dostępu bardzo wielu

309
Journal of Computer Sciences Institute 16 (2020) 309-316

użytkownikom, dla których priorytetem jest natychmia- siedmiu systemów z REST do GraphQL i w związku
stowa i nieprzerwana dostępność usług w sieci [6]. z tym dzięki zastosowaniu GraphQL nastąpiło zmniej-
szenie rozmiaru dokumentów JSON, zwracanych przez
1.2. Testowanie wydajności
interfejsy REST API o 94% w liczbie pól i 99% w licz-
Do sprawdzenia czy system, przy obciążeniu zgodnym bie bajtów (oba wyniki są medianą).
z planowanym wykorzystaniem, będzie nadal działał Brito i Valente [3] wykonali doświadczenie w celu
prawidłowo, a odpowiedzi będą generowane w akcep- porównania wysiłku, jaki trzeba włożyć w generowanie
towanym czasie, służą testy wydajnościowe [5]. Prze- zapytań do GraphQL i implementacje usług webowych
znaczone są one do oceny niezawodności, a co się z tym REST. Badania, w których wzięło udział 22 studentów,
wiąże, jakości oprogramowania internetowego. Odpo- wykazały, że budowanie zapytań GraphQL jest szybsze
wiadają na pytanie, jak duże obciążenie badany system niż implementacja usług REST.
jest w stanie wytrzymać. Głównym celem testów wy- Analizą porównawczą wydajności rozwiązań wyko-
dajnościowych jest zbadanie systemu pod symulowa- rzystujących GraphQL i REST zajmował się Cederlund
nym działaniem wirtualnych użytkowników [7]. Naj- w swojej dysertacji [11]. Jako przypadków testowych
ważniejszym parametrem do oceny wydajności jest używał rzeczywistych aplikacji do oceny opóźnienia,
czas, w którym dany system lub aplikacja musi wyko- objętości danych i liczby zapytań. Przypadki testowe
nać żądaną akcję. Aplikacje internetowe są trudne do zostały tak zaprojektowane, aby możliwe było testowa-
przetestowania, szczególnie pod względem wydajno- nie pojedynczych żądań oraz równoległych i sekwen-
ściowym ze względu na to, że występują kwestie nie- cyjnych przepływów danych. W badaniach skoncentro-
przewidywalne takie jak wielkość obciążenia czy czas wano się na pomiarach czasów odpowiedzi zmieniają-
reakcji [8]. cych się w zależności od wielkości przesyłanych da-
Testowanie wydajności najczęściej odbywa się nych. Wyniki analiz pokazały, że zastosowanie Gra-
w sposób automatyczny i sprowadza się w większości phQL zmniejszyło czas odpowiedzi dla równoległych
przypadków do sprawdzenia poprawnego działania i sekwencyjnych przepływów danych, jednak użycie
badanego systemu pod określonym obciążeniem [7]. pojedynczego, zwykłego endpointa REST gwarantowa-
Zalety testowania automatycznego to przyspieszenie ło najlepszą wydajność.
niektórych czynności, a tym samym skrócenie czasu Taskula w swojej pracy dyplomowej [12] porówny-
całego procesu, eliminacja błędów ludzkich, możliwość wał dwa rozwiązania REST i GraphQL, które wykorzy-
generowania różnego rodzaju raportów, a także reduk- stywał do pobierania danych. W ramach studium przy-
cja kosztów na etapie testowania. Narzędziami stoso- padku wykonane zostały pomiary wydajności, która
wanymi w automatyzacji testów wydajnościowych są te zamieniała się wraz ze zmianami rozmiaru transferowa-
służące do nagrywania, symulowania i rejestrowania nych danych. Okazało się, że w wielu przypadkach
procesu działania aplikacji. testowych GrahpQL lepiej wykorzystywał dane, nato-
miast REST mógł się równać tylko w przypadku inten-
1.3. Przegląd literatury
sywnego filtrowania pól. Dodatkowo w pracy porów-
Na forach i blogach wśród deweloperów oprogramowa- nywano złożoność i możliwość dalszego rozwijania
nia trwa dyskusja na temat, który z istniejących modeli aplikacji z API wykonanego na bazie REST oraz Gra-
architektur (SOAP, REST, GraphQL) będzie najbardziej phQL. Analiza jakościowa wykazała, że realizacja API
optymalny dla danego typu aplikacji. Kwestia ta jest w technologii GraphQL skutkowała mniejszą jego zło-
ciągle przedmiotem badań, których wyniki pojawiają się żonością oraz dawała w przyszłości większe możliwości
w publikacjach naukowych i studenckich pracach dy- rozwoju.
plomowych. W wyniku przeprowadzenia pilotażowego testu [13],
W pracy [9] porównywano wydajność 3 aplikacji porównującego REST z GraphQL okazało się, że pierw-
webowych udostępniających usługi internetowe jedno- sze, starsze rozwiązanie jest szybsze dla prostych
cześnie za pomocą dwóch technologii REST i Gra- ustrukturyzowanych zapytań, takich jak pobieranie
phQL. Zaobserwowano, że w dwóch aplikacjach migra- informacji tylko z jednego źródła lub tabeli. Ponadto
cja do GraphQL spowodowała wzrost wydajności, bio- okazało się, że różnica w wydajności w zakresie czasu
rąc pod uwagę średnią liczbę żądań na sekundę i szyb- odpowiedzi rośnie wykładniczo wraz z rozmiarem bazy
kość przesyłania danych. Jednak dla obciążeń powyżej danych. Pobierając z kolei więcej informacji, GraphQL
3000 żądań usługi oparte na GraphQL działały mniej generuje wolniejsze odpowiedzi w zakresie od 64% do
wydajnie (wyniki w zakresie od 98 do 2159 kB/sek.) od 115%. W przypadku większych baz danych i konstruo-
usług typu REST. Natomiast w przypadku typowych waniu bardziej złożonych zapytań GraphQL lepiej się
obciążeń (100 żądań), usługi oparte na architekturach sprawdzał. Różnica pomiędzy GraphQL i REST wyno-
REST i GraphQL osiągały podobną wydajność z zakre- siła 25%.
su 6,34 – 7,68 żądań/sek. W ramach pracy [14], zaproponowano metodologię,
Korzyści przejścia z API opracowanego na bazie która umożliwiła odpowiedź na pytanie, która technolo-
standardu REST do API zrealizowanego w standardzie gia GraphQL czy REST jest szybsza i lepiej zoptymali-
GraphQL, zebrane od specjalistów mających doświad- zowana. Badaniom poddano start-up - społecznościową
czenie w tym zakresie, poddano praktycznej ocenie w aplikację internetową, w której testowano korzyści
artykule [10]. W tym celu przeprowadzono migrację z migracji z REST do GraphQL. Badania obejmowały

310
Journal of Computer Sciences Institute 16 (2020) 309-316

dwie sytuacje: w pierwszej żądania były przesyłane aplikacji pobierają określone informacje z bazy danych,
w sposób sekwencyjny, a w drugiej równoległy. Głów- której diagram ERD został przedstawiony na rysunku 1.
ny wniosek płynący z pierwszej badanej sytuacji jest
taki, że GraphQL oferuje krótszy czas odpowiedzi dla
każdej sekwencji zapytań. Średnia różnica między
obiema technologiami wyniosła 159 ms, co czyni Gra-
phQL o 46% szybszym od REST. Z drugiej badanej
sytuacji wynika, że także i w tym przypadku GraphQL
był o 35% szybszy niż REST. Ten 11% spadek pomię-
dzy obiema sytuacjami można wytłumaczyć rodzajem
wykonywanych żądań. W przypadku wykonania se-
kwencyjnego drugiego testu, realizacja za pomocą
REST zajęłaby około 3 razy więcej czasu. W związku
z tym schemat równoległy sprawia, że REST staje się
bardziej konkurencyjny w stosunku do GraphQL. Bio-
rąc pod uwagę rozmiar odpowiedzi, w pierwszej sytua-
cji GraphQL był o 21% lżejszy, natomiast w drugiej
o 71%. Rysunek 1: Diagram związków encji
Przywołane prace i ich wyniki nie wskazują jedno-
znacznie, która technologia jest zdecydowanie lepsza. 2.2. Środowisko testowe
Odpowiedź na to pytanie jest uwarunkowana kilkoma Do przeprowadzenia badań wykorzystano dwa kompu-
czynnikami jak na przykład typ i przeznaczenie danego tery przenośne. Jeden z nich pełnił rolę serwera, na
oprogramowania oraz rodzaj i wielkość grupy poten- którym uruchomione zostały dwie usługi webowe:
cjalnych użytkowników. pierwsza zawierająca REST API, druga GraphQL API.
1.4. Cel i zakres pracy Drugi komputer pełnił rolę klienta, na którym zostało
zainstalowane narzędzie umożliwiające przeprowadze-
W Internecie znajduje się dużo publikacji pokazujących nie testów - JMeter w wersji 5.2.1. Parametry poszcze-
zalety i wady stylów wymiany danych REST i Gra- gólnych urządzeń wykorzystanych do badań oraz opis
phQL. Jednak wciąż niewiele artykułów odpowiada na serwera bazy danych, serwera HTTP i parametrów sieci
pytanie, które rozwiązanie jest lepsze, potwierdzając znajdują się w tabelach 1, 2 i 3.
równocześnie to w sposób ilościowy na podstawie wy-
ników z przeprowadzonych badań. Celem tej pracy jest Tabela 1: Opis komputera pełniącego rolę serwera
dalsze wypełnienie tej luki poprzez przeprowadzenie Procesor Intel(R) Core(TM) i7-6700HQ
analizy porównawczej wydajności dwóch technologii CPU @ 2.60 GHz, 2601MHZ,
internetowych REST i GraphQL. Rdzenie: 4, Procesory logicz-
Zakres pracy obejmował następujące elementy: ne: 8
opracowanie aplikacji testowych, przygotowanie ekspe- Pamięć RAM 16 GB
rymentu, dobór narzędzia diagnostycznego, zrealizowa- Karta sieciowa Intel(R) Dual Band Wireless-
nie zautomatyzowanych testów wydajnościowych oraz AC 3165
opracowanie wyników i ich interpretację. System operacyjny Microsoft Windows 10 Pro
W pracy postawiono tezę badawczą, którą sformu- Serwer bazy danych MariaDB 10.1.25
łowano w następujący sposób:
Serwer HTTP Apache Tomcat 9.0.3
Aplikacje wykorzystujące rozwiązanie GraphQL w sytu-
acjach, w których klient potrzebuje zestawu danych Tabela 2: Opis komputera pełniącego rolę klienta
w określonym formacie i możliwie najmniejszym roz- Procesor Intel(R) Core(TM) i3-2350M
miarze, mają lepszą wydajność w porównaniu do apli- CPU @ 2.30 GHz, 2300 MHz,
kacji stosujących REST. Rdzenie: 2, Procesory logicz-
2. Metoda badań ne: 4
Pamięć RAM 6 GB
2.1. Aplikacje testowe Karta sieciowa Intel(R) Centrino(R) Wireless-
Na potrzeby badań utworzono dwie usługi - aplikacje N 130
webowe zawierające te same funkcjonalności, ale wy- System operacyjny Windows 7 Home Premium
korzystujące odmienne style wymiany danych: REST Tabela 3: Opis sieci Wi-Fi
i GraphQL. W związku z tym w obu aplikacjach zaim-
plementowano odpowiednie API i poddano je testom Protokół Wi-Fi 4 (802.11n)
sprawdzającym ich wydajność. Zadaniem przygotowa- Pasmo sieci 2.4 GHz
nego oprogramowania było zarządzanie danymi doty- Średnia prędkość 16383 kbps
czącymi przeprowadzonych testów: informacjami na pobierania danych
temat uczniów, nauczycieli, kursów oraz budynków, Średnia prędkość 1052 kbps
w których odbywały się egzaminy. Warstwy serwerowe wysyłania danych

311
Journal of Computer Sciences Institute 16 (2020) 309-316

2.3. Narzędzie badawcze różnej liczby użytkowników, korzystających równocze-

śnie z aplikacji.
Do testów wydajnościowych użyto programu Apache
Do porównania wydajności aplikacji, wykorzystują-
JMeter, który jest narzędziem typu open source napisa-
cych różne style wymiany danych posłużono się trzema
nym w języku Java z wykorzystaniem biblioteki Swing
metrykami:
[15]. Oprogramowanie to umożliwia automatyczne
• całkowitym czasem przetworzenia żądań wyrażo-
analizowanie wydajności różnych usług (w tym aplika-
nym w milisekundach,
cji internetowych) pod dużym obciążeniem, przy rów-
noczesnej pracy wielu użytkowników. JMeter został • rozmiarem danych pobieranych w bajtach,
wybrany do przeprowadzenia badań z następujących • rozmiarem danych wysyłanych w bajtach.
względów [9]: 3. Wyniki badań
• program jest dostępny bezpłatnie,
• posiada czytelny i intuicyjny interfejs użytkownika, 3.1. Wyświetlanie danych
• daje możliwość tworzenia symulacji korzystania Przypadek 1: Nadmiarowe pobieranie wszystkich da-
z aplikacji przez wielu użytkowników jako oddziel- nych poprzez jeden endpoint REST API versus pobiera-
nych wątków, nie ściśle określonych danych poprzez API oparte na
• obsługuje wiele protokołów w tym HTTP, SOAP, GraphQL
POP3, itd.,
• udostępnia możliwość tworzenia zapytań HTTP W przygotowanej usłudze internetowej bazującej na
korzystając z jego metod (GET, POST) oraz pozwa- architekturze REST został utworzony jeden endpoint
la na przetwarzanie wyników odpowiedzi, /app/testy, poprzez który możliwe było pobranie
• umożliwia opracowanie zaawansowanych scenariu- wszystkich danych dotyczących przeprowadzonych
szy testowania, testów wraz z informacjami o uczniu, nauczycielu,
• wyniki testów można prezentować za pomocą kursie oraz budynku, w którym odbywał się egzamin.
drzew, tabeli i wykresów. W wielu sytuacjach klient może nie potrzebować tylu
JMeter jest zaawansowanym i kompleksowym roz- informacji. Ilość otrzymywanych informacji powinna
wiązaniem do wykonywania nie tylko testów wydajno- uwzględniać typ (komputer, tablet, smartfon) i specyfi-
ściowo-obciążeniowych, ale również testów jednostko- kę urządzenia (np. rozdzielczość ekranu, moc oblicze-
wych, funkcjonalnych i regresyjnych. Osobom używa- niowa), na którym liczba jednocześnie wyświetlanych
jącym tego narzędzia nie stawia wysokich wymagań co informacji może być różna. W części tej zbadano wy-
do ich umiejętności informatycznych – wymagana jest dajność obu aplikacji w sytuacji, gdy serwis oparty na
jedynie znajomość technologii HTML oraz konstruo- REST przekazuje często nadmiarowo wszystkie dane,
wania wyrażeń regularnych. a serwis oparty na GraphQL tylko dane ściśle określone
i wymagane przez użytkownika. Ilość pobieranych
2.4. Scenariusze badawcze danych może być również uzależniona i automatycznie
Opracowano eksperyment, w ramach którego testowano dobierana do urządzenia, na którym będą one wyświe-
podstawowe operacje umożliwiające zarządzanie dany- tlane lub przetwarzane, biorąc pod uwagę rozdzielczość
mi w bazie danych występujące w większości usług ekranu czy moc obliczeniową.
sieciowych: wyświetlanie, dodawanie, aktualizowanie Na rysunkach 2, 3 i 4, w postaci wykresów linio-
oraz usuwanie danych. Najwięcej uwagi poświęcono wych, przedstawiono wyniki ukazujące wydajność te-
operacji wyświetlania informacji, w zakresie której stowanych aplikacji opartych na dwóch stylach wymia-
rozpatrywano trzy przypadki testowe: ny danych REST i GraphQL. Oś Y reprezentuje całko-
1. nadmiarowego pobierania wszystkich danych przez wity czas przetwarzania żądań wyrażony w milisekun-
jeden endpoint REST API oraz pobierania ściśle dach, natomiast oś X liczbę użytkowników jednocześnie
określonych danych poprzez API oparte na Gra- wywołujących żądanie.
phQL;
2. pobierania wszystkich danych przez REST API
(1 endpoint) oraz pobierania wszystkich danych po-
przez GraphQL API;
3. pobierania kompletu danych z kilku endpointów
REST API i jednego endpointa GraphQL API.
Badanie operacji wyświetlania (pierwszy i drugi
przypadek) zostało przeprowadzone dla różnej liczby
użytkowników generujących jednocześnie żądania (1, 5,
50, 100, 500 i 1000) oraz dla różnej liczby rekordów
pobieranych z bazy (5, 50, 100). Przy testowaniu apli-
kacji podczas wykonywania operacji dodawania, usu-
wania czy edytowania danych nie zmieniano warunków Rysunek 2: Wyświetlanie danych (rozmiar: 5 rekordów).
obciążeniowych: tzn. nie brano pod uwagę przypadków
testowania dla różnej liczby testów w bazie danych oraz

312
Journal of Computer Sciences Institute 16 (2020) 309-316

testu, podobnie jak to miało miejsce w przypadku 1

w aplikacji korzystającej z architektury REST. Rysunki
6, 7 i 8 odzwierciedlają wyniki wydajności, traktowanej
jako całkowity czas przetwarzania żądań, uzyskane
przez obie aplikacje testowe.

Rysunek 3: Wyświetlanie danych (rozmiar: 50 rekordów).

Rysunek 6: Wyświetlanie danych (rozmiar: 5 rekordów).

Rysunek 4: Wyświetlanie danych (rozmiar: 100 rekordów).

Na wykresach 2, 3 i 4 wyraźnie widać duży spadek

wydajności aplikacji wykorzystującej styl REST, przy
dużej liczbie użytkowników (>100) wysyłających jed-
nocześnie żądania, zarówno w przypadku gdy otrzy-
mywano 5, 50 czy 100 rekordów. Zaobserwowany duży Rysunek 7: Wyświetlanie danych (rozmiar: 50 rekordów).
spadek wydajności był spowodowany tym, że wielkość
otrzymywanych danych w przypadku zastosowania
architektury REST jest trzy razy większa w porównaniu
z technologią GraphQL (rysunek 5).

Rysunek 8: Wyświetlanie danych (rozmiar: 100 rekordów).

W przypadku 2, kiedy pobierana jest jednakowa

ilość danych, przy dużym obciążeniu (>500 użytkowni-
ków), sytuacja staje się bardziej skomplikowana. Zasto-
Rysunek 5: Rozmiar otrzymanych danych - REST vs GraphQL. sowanie GraphQL okazało się bardziej wydajne, gdy
Przypadek 2: Jednakowa liczba otrzymywanych (po- pobierana była mała ilość danych: 5 rekordów (rysunek
bieranych) danych - pobieranie wszystkich danych przez 6) i gdy liczba użytkowników generujących żądania
REST API (przez 1 endpoint) oraz pobieranie wszyst- była większa niż 500. W przypadku pobierania 50 re-
kich danych poprzez GraphQL API kordów, niezależnie od liczby użytkowników wydaj-
ność obu aplikacji była podobna. Usługa oparta na
Drugi przypadek polegał na pomiarze tych samych REST okazała się bardziej wydajna podczas jednocze-
parametrów, tym razem podczas otrzymywania tej sa- snego wyświetlania dużych ilości danych (100 rekor-
mej ilości informacji. W tym celu w aplikacji opartej na dów) począwszy od liczby stu użytkowników.
GraphQL klient pobierał wszystkie dane dotyczące Jeśli chodzi o rozmiar otrzymywanych danych (ry-
sunek 9), to był on w przybliżeniu jednakowy, nato-

313
Journal of Computer Sciences Institute 16 (2020) 309-316

miast rozmiar wysłanych danych był zdecydowanie czekał na przetworzenie żądania średnio 144 ms.
większy po stronie aplikacji wykorzystującej GraphQL W GraphQL ta sama operacja była wykonywana
(727 bajtów) w porównaniu do REST (133 bajtów). w czasie średnio 123 ms.

Rysunek 9: Rozmiar otrzymanych danych - REST vs GraphQL. Rysunek 10: Porównanie rozmiarów danych w REST i GraphQL.

Przypadek 3: Pobieranie kompletu danych z kilku 3.3. Aktualizowanie danych

endpointów REST API i jednego endpointa GraphQL Podczas operacji aktualizowania danych nie zaobser-
API wowano różnicy w czasach przetworzenia żądania
Technologie webowe oparte na GraphQL są mniej w przypadku obu aplikacji testowych. Uzyskane średnie
złożone, gdyż wykorzystują jeden stały endpoint. wartości czasu wykonania operacji edycji danych były
Z kolei aplikacje bazujące na architekturze REST ko- praktycznie jednakowe (12 milisekund w aplikacji opar-
rzystają z wielu endpointów. W ostatnim przypadku tej na REST i 13 milisekund dla aplikacji z GraphQL).
przeanalizowano i porównano wydajność technologii Natomiast różnice można zauważyć w rozmiarach
REST i GraphQL podczas pobierania tych samych da- otrzymanych i wysyłanych danych, podobnie jak to
nych w sytuacji gdy aplikacja z REST korzysta z kilku miało miejsce podczas dodawania informacji do bazy
endpointów, a aplikacja oparta na GraphQL tylko danych. Rysunek 11 pokazuje, że w tej operacji lepsze
z jednego endpointa. wyniki osiągnął klient, komunikując się z serwisem
W technologii webowej opartej o REST chcąc uzy- opartym na REST.
skać informacje o określonym kursie, należało użyć
odpowiedniego adresu, innego niż na przykład przy
otrzymywaniu informacji o danym budynku. Do celów
badań została zasymulowana sytuacja, w której klient
chce uzyskać pełne informacje o uczniu, nauczycielu
i \budynku z określonymi identyfikatorami. W tym
przypadku uzyskane czasy przetworzenia żądania były
krótsze dla aplikacji wykorzystującej GraphQL. Także
rozmiar otrzymanych danych był mniejszy w aplikacji
korzystającej z GraphQL, a wysłanych w aplikacji
z REST API (tabela 4).
Tabela 4: Porównanie otrzymanych wartości badanych parametrów
w aplikacjach z REST i GraphQL
Rysunek 11: Porównanie rozmiarów danych w REST i GraphQL.
Interfejs Czas prze- Rozmiar Rozmiar
(API) tworzenia wszystkich wszystkich 3.4. Usuwanie danych
żądań (ms) pobranych wysłanych Ostatnią testowaną operacją dla opracowanych usług
danych danych internetowych było usuwanie danych z bazy. W obu
(bajty) (bajty) aplikacjach czasy przetworzenia żądań miały podobne
wielkości (tabela 5). W usłudze bazującej na interfejsie
REST 21 1091 404
REST, klient, aby usunąć określony budynek z bazy
GraphQL 15 894 667 danych potrzebował przesłać żądanie o rozmiarze 187
3.2. Dodawanie danych bajtów. Natomiast w aplikacji wykorzystującej Gra-
phQL API, klient wysyłał żądanie zawierające 286
Podczas dodawania rekordu do bazy lepsze rezultaty bajtów. Z tego wynika, że w tej sytuacji lepiej wypada
odnoszące się do rozmiaru otrzymanych jak i wysłanych aplikacja wykorzystująca interfejs REST. Jednak należy
informacji, dało się zauważyć w usłudze opartej na stylu pamiętać, że każdy rekord w bazie danych w usłudze
REST (rysunek 10). Jednak czas przetworzenia żądania z REST API posiada swój odrębny adres, który pozwala
był lepszy w przypadku aplikacji z GraphQL. Klient, na jego usunięcie. W rozwiązaniu stosującym GraphQL
aby dodać dane o nowym budynku w aplikacji z REST klient posługuje się jednym, stały endpointem, co zde-

314
Journal of Computer Sciences Institute 16 (2020) 309-316

cydowanie ułatwia komunikację. Kolejną rzeczą, na usługę otrzymywał tę samą ilość danych (wszystkie
którą trzeba zwrócić uwagę jest to, że przy próbie usu- dane) i to ta część badań potwierdziła postawioną na
nięcia encji (również przy edycji danych), która nie początku pracy tezę. W obu technologiach, przy pobie-
istnieje w bazie, w podejściu REST klient otrzyma błąd raniu małych porcji danych (5 rekordów) przez 1 endpo-
wykonania żądania. W technologii GraphQL klient zaś int, przy dużym obciążeniu, lepiej wypadała usługa
otrzyma status 200 HTTP, oznaczający poprawne prze- stosująca GraphQL. Jednak w podobnych warunkach,
tworzenie żądania, co może powodować wyświetlanie w przypadku pobierania dużych porcji danych (100
niewłaściwego komunikatu po stronie klienta (tabela 6). rekordów) bardziej wydajna była usługa wykorzystująca
Tabela 5: Rezultat wykonania żądania usunięcia rekordu z bazy
interfejs REST. Rozmiar wysyłanych danych był więk-
danych w aplikacjach stosujących styl REST i GraphQL szy w GraphQL, ponieważ klient w przesyłanej wiado-
mości musiał przy pomocy języka zapytań zawrzeć
Czas Rozmiar Rozmiar
wszystkie informacje, które chciał uzyskać w odpowie-
Technologia

przetwo- pobranych wysłanych

dzi. Należy zatem podkreślić, że zapytania w GraphQL
Status

rzenia danych danych

żądania (bajty) (bajty) mogą być zawiłe i skomplikowane.
(ms) Podczas pobierania kompletu danych z kilku endpo-
intów REST API i jednego endpointa GraphQL API
REST 535 OK 187 215
uzyskane czasy przetworzenia żądania były krótsze dla
GraphQL 495 OK 286 238
aplikacji wykorzystującej GraphQL. Rozmiar otrzyma-
Tabela 6: Rezultat wykonania żądania usunięcia rekordu, który nie nych danych był mniejszy w aplikacji korzystającej
istnieje w bazie danych w aplikacjach z REST oraz GraphQL z GraphQL, a wysłanych w aplikacji z REST API.
Czas Rozmiar Rozmiar W przypadku operacji dodawania, edycji i usuwania
Technologia

przetwo- pobranych wysłanych danych z bazy, porównywane były czasy przetwarzania

Status

rzenia danych danych pojedynczych żądań. Analiza czasów wykazała, że

żądania (bajty) (bajty) różnice w wydajności przetwarzania żądań były mini-
(ms) malne. Jeśli chodzi o wielkość wysyłanych i pobiera-
REST 56 Błąd 307 215 nych informacji, we wszystkich wyżej wymienionych
GraphQL 22 OK 389 238 operacjach bardziej wydajny okazywał się interfejs
opracowany na bazie technologii REST.
4. Wnioski
Literatura
Wyniki badań empirycznych są bardzo pomocne przed
podjęciem decyzji o wyborze najbardziej optymalnego [1] R.T. Fielding, Architectural Styles and the Design of
rozwiązania w procesie wytwarzania oprogramowania. Network-based Software Architectures, Ph.D, University
W związku z tym, w niniejszej pracy przeprowadzono of California, Irvine, 2000.
analizę porównawczą pod względem wydajności [2] R. T. Fielding, R. N. Taylor, Principled design of the
dwóch, szeroko stosowanych obecnie podejść do budo- modern Web architecture, Proceedings of the 2000
wy interfejsu API: REST i GraphQL. Badania zostały International Conference on Software Engineering. ICSE
zrealizowane na utworzonych do tego celu dwóch usłu- 2000 the New Millennium, Limerick, Ireland,
gach, z których pierwsza do wymiany danych używała 2000: 407-416, https://doi.org/10.1145/337180.337228,
[10.07.2020].
architektury REST, natomiast druga wykorzystywała
język i silnik GraphQL. Do pomiarów czasów przetwa- [3] G. Brito, M. T. Valente, REST vs GraphQL:
rzania żądań oraz rozmiarów wysyłanych i pobieranych A Controlled Experiment, 2020 IEEE International
danych posłużyło narzędzie diagnostyczne JMeter. Conference on Software Architecture (ICSA), 81-91,
Zrealizowane badania pokazały, kiedy i jakie różni- [10.07.2020].
ce występują między obiema technologiami w kontek- [4] GraphQL, http://spec.graphql.org/, [10.07.2020].
ście ich wydajności. W przypadku operacji wyświetla-
[5] M. Prywata, Testowanie aplikacji i stron internetowych,
nia, klient korzystający z usługi internetowej opartej na Polska Agencja Rozwoju przedsiębiorczości, Warszawa,
REST, nie może ograniczyć liczby otrzymywanych 2009, https://www.parp.gov.pl/publications/publication/
danych, ponieważ zawsze w odpowiedzi otrzyma pełny testowanie-aplikacji-i-stron-internetowych, [09.07.2020].
zestaw informacji. W tej sytuacji część danych może
być dla klienta niepotrzebna. Natomiast w GraphQL to [6] S. Sharmila, E. Ramadevi, Analysis of Performance
Testing on Web Application, International Journal of
klient określa, posługując się językiem zapytań, jakie
Advanced Research in Computer and Communication
informacje chce uzyskać w odpowiedzi od serwera. Engineering, Vol. 3, Issue 3 (2014),
W tym przypadku, bez względu na liczbę pobieranych https://ijarcce.com/wp-content/uploads/2012/03/
rekordów z bazy, usługa internetowa oparta IJARCCE4H-s-sharmila-Analysis-of-Performance-
na GraphQL szybciej przetwarzała żądania niż miało to Testing-on-Web-Applications.pdf, [10.07.2020].
miejsce w aplikacji z interfejsem REST. Wynikało to
[7] P. Marek, Weryfikacja i automatyzacja procesu
głównie z ilości otrzymywanych danych, która była testowania oprogramowania, CORE Magazine, 2010.
ponad trzykrotnie mniejsza w GraphQL niż w REST.
Kluczowym rozpatrywanym przypadkiem, była sy- [8] S. Dhiman, P. Sharma, Performance Testing:
tuacja, gdy klient zarówno poprzez jedną jak i drugą A Comparative Study and Analysis of Web Service
Testing Tools, International Journal of Computer Science

315
Journal of Computer Sciences Institute 16 (2020) 309-316

and Mobile Computing, Vol. 5, Issue 6, (2016) 507-512, Realy+GraphQL, Dissertation, KTH, 2016,
https://www.ijcsmc.com/docs/papers/June2016/V5I6201 http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-196058,
697.pdf, [09.07.2020]. [27.08.2020].
[9] M. Seabra, F. Nazario, G. Pinto, REST or GraphQL?: A [12] T. Taskula, Advanced data fetching with graphql: Case
Performance Comparative Study, In Proceedings of the bakery service, Dissertation, Aalto University, 2019,
XIII Brazilian Symposium on Software Components, https://aaltodoc.aalto.fi/handle/123456789/37147,
Architectures, and Reuse (SBCARS '19). Association for [27.08.2020].
Computing Machinery, New York, NY, USA, 123–132.
[13] A. F. Helgason, Performance analysis of Web Services:
https://doi.org/10.1145/3357141.3357149, [27.08.2020].
Comparison between RESTful & GraphQL web services,
[10] G. Brito, T. Mombach, M. T. Valente, Migrating to Dissertation, University of Skövde, 2017, http://his.diva-
GraphQL: A Practical Assessment, In 2019 IEEE 26 th portal.org/smash/record.jsf?pid=diva2%3A1107850&ds
International Conference on Software Analysis, wid=-9534, [29.08.2020].
Evolution and Reengineering (SANER), 140-150,
[14] C. Oggier, How fast GraphQL is compared to REST
https://doi.org/10.1109/SANER.2019.8667986,
[27.08.2020]. APIs, Dissertation, Haaga-Helia University of Applied
Sciences, 2020, http://urn.fi/URN:NBN:fi:amk-
[11] M. Cederlund, Performance of frameworks for 2020052714286, [29.08.2020].
declarative data fetching: An evaluation of Falcor and
[15] Apache JMeter, http://jmeter.apache.org/, [09.07.2020].

316