Comparison of REST server implementation with Laravel and [605604]

Comparison of REST server implementation with Laravel and
Node.js

UNGUREANU Anca1, ROMAN Adrian2, NOVAC Ovidiu Constantin3

University of Oradea, Romania, 1Master Student: [anonimizat],
2 Master Student: [anonimizat],
3Department of Electrical Engineering, Faculty of Electrical Engineering and Information Technology,
1, Universității Str., 410087 Oradea, Romania, E-Mail: [anonimizat]

Abstract – In this paper we present two types of REST
server implementation, we will look at the advantages
and disadvantages of each one. Laravel is a PHP open-
source framework for backend development, based on
Symfony. Node.JS is an open-source Javascript runtime
environment that executes Javascript code.

Keywords: REST; server; backend; laravel; node.JS;
framework;

I. INTRODUCTION

The massive evolution of technology and the inclusion of
computers in day to day activities resulted in the creation
of a wide and diverse category of software solutions,
which are meant to solve different problems. The fact that
a large chunk of the population uses these said solutions
raises a new major problem: the need to store and process
a large amount of data rapidly, efficiently and most of all
in a flexible manner. Data structuring inside an
application is a vital step in the development process,
having an impact in the usability of the app itself. It not
only has a major impact on response timing, but also on
the flexibility of adding new features to the app itself,
therefore we could say that this particular aspect could
make the difference between a successful app and a
failure.
Up until recently, building a website meant building a
custom complete PHP solution for each project. A PHP
server would follow the MVC architecture (Model-View-
Controller)1, where a model would make up the
information about the state of server, generally in the
form of a SQL database. This data would be extracted and
interpreted by the server, and the server would build a
view from this, using HTML, CSS, and Javascript. The
view would be presented to the user and when the user
would interact with it, the view would send the new
information to the controller component of the server,
which would interpret the changes made on the view and
make the necessary adjustments to the database or the
state of the application, also known as the model. When
the operation was complete, the model has been changed and therefore the server would build another view based
on the new information from the model. However, due to
the massive growth of demand for web applications, the
websites grew more and more complex, and therefore the
processing time grew considerably. This resulted in a
gross general dissatisfaction for the users, so in order to
speed up the interface, programmers started separating
the view component from the server component. Thus the
three-tier architecture was created, separating the server
into frontend as the client interface, backend for the
business logic, and data, for storing meaningful
information.
As this architecture dictates, the server would still receive
and process the data from the frontend through requests,
but it would no longer need to render the view, just pass
the result of the processing back to the frontend
component. Thus some of the servers have stopped being
complete solutions, and have turned into Application
Programming Interfaces(API), or web services. A type of
web service that exchanges text-style data through a
uniform set of stateless operations is called an
Representational State Transfer(REST) web service, or a
REST API.2
The scope of this paper is the backend component,
namely how a PHP server with the Laravel framework
would perform as a REST API against a Node.js server
with the Express framework. Node.js was purposely
designed for building REST API’s, but was released more
than 10 years ago and it has yet to overthrow PHP as the
most used server implementation despite it’s constant
growth, and PHP’s constand descend.3 However, in
recent years, there has been a large growth in the use of
internet of things and cloud computing, which generally
use REST as their main communication method, so we
believe that, nowadays, it’s better for many projects to use
a REST API as it’s server. Therefore the aim of this paper
is to compare which of the two most popular server
implementations, PHP and Node.js, would the better
choice for this task.

II. PHP & LARAVEL

A. PHP

Php is a scripting language, best suited for web
development.4 Created in 1994, PHP initially stood for
Personal Home Page, but now it is a recursive acronym
for PHP: Hypertext Preprocessor. It is used as a simpler
way of displaying information and interfaces by using
both HTML code and php embedded in the same file. The
php code is delimited by starting and closing php tags
(<?php and ?>). The difference between PHP and other
web development languages is the fact that the code is
executed on the server, it generates an HTML code which
is then sent to the client for displaying.5 Therefore the
client receives the executed code without having to know
what happens behind the stage.

B. Laravel

Laravel is a free, open-source PHP web framework based
on Symfony. It was released for the first time in 2011 by
Taylor Otwell, who created it as a way to develop web
applications following the MVC (Model-View-
Controller) architectural pattern. It provides support for
both frontend and backend development, using features
such as Blade (a templating engine), spaghetti HTML,
Views etc, to achieve this goal.
Database interactions are simplified due to the existence
of Eloquent ORM (Object-Relational Mapping), a PHP
implementation of active record pattern, which offers
support for defining relationships between database
tables. It provides a large number of classes and internal
methods for easier database handling.

III. NODE.JS & Express.js

A. Node.js
Node.js is a cross-platform, open-source, asynchronous
event-driven Javascript runtime that uses non-blocking
I/O operations. According to their website, Node.js is
used to build scalable network applications6. It was
written in C++ by Ryan Dahl in 2009 and it uses the V8
open-source engine from Google to compile the
Javascript code into byte-code and it accesses the I/O
through an API7. Due to its relatively simple structure and
small codebase, in the early stages implementing a server
with Node.js meant using a lot of duplicated code.
Therefore in 2010 a package manager called NPM was
launched in order to allow developers to place reusable
code into modules that could be imported and exported to
any project using NPM. Today, Node.js is used by
companies like IBM, Microsoft, Netflix, Paypal,
Rakuten, SAP and others8.

B. Express

One of the most popular packages for server development
on NPM is the open-source Express framework.
According to their website “Express is a minimal and
flexible Node.js web application framework that provides
a robust set of features for web and mobile applications”9. It was released in 2010, and today it is used by big
companies like IBM, PayPal, Uber and others.10 Express
was inspired by Sinatra11 as a light-weight layer between
the server routes and the code through the principle of
middlewares. It’s aim is to speed up the development of
web servers by empowering developers with the tools that
Node.js does not provide like routing or role-checking.

IV. COMPARING LARAVEL SERVER
IMPLEMENTATION WITH NODE.JS
IMPLEMENTATION

First of all we should understand how each technology
stack works, then we will review how easy it is to extend
the functionality with external modules, and finally we
will present sintetic speed results.

A. Implementation

Let’s start with Node.js. As mentioned before, Node.js is
a Javascript runtime environment, which means that in
order for us to run Javascript on a machine we need to use
Node.js as an interpreter that converts the Javascript code
into runnable code. Same goes for PHP, which can not be
interpreted by the system as is, so it too needs to be
paresd, compiled, and translated into bytecode. When we
want to run a PHP project, all files in the project must be
compiled, whereas Node.js is using JIT (Just-in-Time)
compilation, which means that it will only translate and
run the javascript code when it is needed, and only the
code that is needed. Even though both PHP and Node.js
can respond to web requests on their own, due to security
reasons and load balancing we should run the PHP
process behind an Apache server, and the Node.js process
behind an Nginx server. For this test we ignored this
recommendation and went with standalone servers.
When a PHP server receives a request it will decipher the
route and decide which controller and function to be
called for processing the needed operation. Since all the
code is already compiled, PHP will start a worker thread
to runs synchronously through all the lines in the function
body, until it reaches the exit point where it will return the
response to the client. Since some tasks can take longer,
the thread will wait for said operations to complete before
moving forward. Most of these operations are I/O
operations, like file accesses or database queries, and
therefore it is said that PHP takes a blocking I/O
approach.
When a Node.js server receives a request, it must call the
“handler” function that is registered to be called on a
specific route. This function is placed on the call stack by
the event loop, as shown in Fig.1, a javascript specific
mechanism that periodically checks specific registered
calls in the runtime.

Fig. 1 A conceptual representation of the Event Loop12

Only when the time comes to execute a javascript
function, aka it has reached the top of the stack, Node.js
will compile its code and pass it to the host machine for
execution. While these functions execute, the I/O on the
host system is stuck, but thanks to this event loop, the
Node.js server is still running and can still serve, compile
and execute other javascript functions, from other clients.
This is what the creator of Node.js calls Non-Blocking
I/O. In most cases, after the function is executed, we want
a result, either to confirm the function has ended
correctly, or because we want some data back – for
example when extracting data from the database or when
requesting a resource, like a photo or a font file, from a
remote storage server. When a function is passed to the
event loop, it gets called, but it is also detached from the
caller. So normally the protocol is to send a “callback”
function as a parameter to the system call. When the
system function has finished executing, it’s last step is to
send the callback function to an internal listener.
Obviously, the event loop will check this listener as well,
and it will pick up the function and add it to the call stack,
where it will be once again executed when it’s time
comes. This callback can be another call to the I/O, or it
can be the response for the request, but nonetheless, all
functions go through the event loop.
Considering what we know about the way Node.js and
PHP work, we should now compare their architectures.
Typically, a PHP & Laravel web server follows the MVC
architecture because it was designed to provide a
complete solution, unlike Node.js which can only provide
the backend implementation.
In an MVC project, a model would generally consist of
the information about the state of server, usually in the
form of a database. This data would be extracted and
interpreted by the server, and it would build a view from
this. The view would be presented to the user and when
the user would interact with it, the view would send the
new information to the controller component of the server
by using requests. Upon arriving, the request is directed
to the corresponding function in a controller. This
function will perform all the necessary operations, such
as checking privileges, data validation, database
interaction, and others. In general, after a request is
processed, it would return a .html file, with HTML and
PHP code which will be rendered by the browser. Even
though there are many ways to go about building this
view, with the most popular one being Blade, the
templating engine that ships with Laravel, a REST API
should only send a text file, in which the data is structured in a specific format, the most popular one being JSON,
but XML or Protobuf are viable alternatives. So, in order
to have a better comparison between the two we adapted
the typical MVC pattern to transform the view component
into a simple text representation of the data in JSON
format. Though it may not be very useful for the user, it’s
actually much more useful for a frontend implementation
since it’s easier to parse. Therefore we decided to build
the graphical interface separately via an Angular project,
which, as shown in Fig. 2, would take the role of the user
and interact with our PHP server through requests and
responses.

Fig. 2 MVC block diagram example13
We cannot say that Node.js follows a specific
architecture, just that it can play a role in many web stacks
that follow different architectures. For example, it could
play a part in a microservice architecture, where each
Node.js server would execute just a few tasks specific to
a module, and communicate with the others via requests.
But in our test project we implemented a project based on
the MEAN Stack14, composed of Mongo, Express,
Angular and Node.js, that follows the Three-tier
architecture, as shown in Fig. 3, where we would use
Angular to create the Presentation layer or tier, which
takes care of rendering the view and has its own model of
data, a Node.js & Express REST API for business layer,
where we incorporate the classical controller that does not
need a model, just the logic needed to connect the front-
end model with the database through REST API calls, and
MongoDB as the data tier. The big advantage that this
stack brings is that all of the components understand
Javascript and they communicate through JSON
(Javascript Object Notation) objects, therefore an object
created in the client tier can be passed to the business tier
to be processed and then sent to the data Layer to be
stored without additional processing, which speeds up the
response time.

Fig. 3. MEAN Stack Three tier Architecture.15
The implementation of the REST API in Node.js &
Express is not at all complicated. Each call is received in

the app.js file where, depending on the first part of the
route, corresponding to the module it is directed to the
route file specific to that module. From there, also
depending on the route and the token, if it is a protected
route, the server calls a specific function from the
controller. Each module has a controller, which extracts
the data from the request, and if the data is valid, then the
controller may call methods from one or many services,
if the method requested needs to execute a lot operations,
like for example extracting the profile of a user along with
his stored files or photos. These services are generally
corespondent to each table or collection in the database,
and the methods in these services are wrappers for queries
that need to execute on a specific table. When the
database query is done executing, it will call a callback
function sent as argument to the service method. This
callback function was created in the controller and deals
with the outcomes of the query, and the data it has
returned. Regardless of the outcome of the query, all the
callback methods must call a exit method, to return a
JSON object to client, whether this object contains the
data requested or an error message explaining why this
occurred.
When it comes down to comparing architectures, it’s
apples and oranges, since PHP and Node.js have been
built in very different mindsets. However, since they are
both backend implementations, from a execution point of
view, we believe that event driven execution and Non-
blocking I/O are two very striking advantages for a REST
API so we believe that the Node.js architecture is the most
appropriate for the job.

B. Packages and extensions

Today, a rather common practice is to build reusable code
and actually use code already written, by you or by others,
in order to speed up the development and to not bother
“reinventing the wheel”16. But in the old days each project
had to be built from scratch so reusability was not a major
priority. This was mainly due to the fact that it was rather
hard to share code between different projects and
machines because each had a specific configuration. But
in 1999, Stig Bakken founded the PEAR project in order
to boost reusability and help programmers build PHP
servers easier and faster. Today, almost every modern
language comes with a package manager. For Python it’s
called Pip, for Ruby it’s Bundler, for Node it’s NPM and
for PHP it’s composer. Even though PEAR is not very
used today, it provided the basis for reusability and
inspired the now-popular package managers.
In our opinion, package managers are important because
they can provide an insight into the size of the developer
community around a certain language, not just by
counting the total number of packages, but also the
average number of packages, either released or updated
in the last month or year. Both languages and frameworks
are open source, so by measuring how often the packages
are updated, we can get a sense of the usability and
popularity of the language. Generally, programmers and
companies who use a certain software want it to be as fast and robust as possible, but also easily scalable and
expandable. So an Active community will constantly
update the packages to patch the latest security
vulnerabilities, support the latest performance
developments or stability improvements, and also release
new modules with new functionality based on the
demand. So the more an open source software is used, the
higher the interest in the language or framework, and
therefore the higher the number of updates released,
which in turn will determine new programmers or
companies to use it, making it more widespread and so
on.
If we dive into the numbers, PHP released version 7.4 in
28 Nov. 2019 and will continue to actively support it until
28 Nov. 2021. The previous version, 7.3 was released in
6 Dec. 2018, and is supported until 6 Dec. 2020.17
Laravel’s current version is 7, which was released Mar.
3rd 2020, and will be updated until Sep 3rd, 2020. After
that, Laravel 8 will be released, which in turn will be
supported until Mar. 3rd 2021. The Composer package
library, called Packagist, reports 250 thousand active
packages and over 2.2 million versions available.
Node.js is currently at version 14, which was released in
the 21st Apr. 2020, and will be supported until 19 Oct.
2021. The previous version, v12, was released in 23 Apr.
2019 and is supported until 20 Oct. 202018. Express’s
current version is 4.17, released over a year ago, because
version 5 is still in development, despite the first alpha
release being mode than 5 years ago. NPM is said to have
more than a million packages, but we should keep in mind
that this includes packages for all Javascript-based
frameworks, like Angular, React, Ionic, Deno, etc.
It is clear that both implementations are popular and well
maintained, with a large community of developers that
work hard for improving them. Therefore, in this category
we cannot crown a clear winner.

C. Scalability and performance

As said before, the vast majority of web services use a
PHP backend, or a complete PHP solution, but Node.js
keeps improving its market share. Perhaps a big selling
point is performance and scalability. So we tried to
compare our implementations by using Apache AB
benchmarking tool, a command line tool made by Apache
software foundation that comes included with Apache
Server. Upon researching this topic we came across an
article that compared a Node.js server implementation to
a PHP Zend implementation and a PHP HHVM one19. For
simple HTTP GET requests, measured with Apache AB
benchmarking tool, HHVM was 75% faster than Zend,
but 17% slower than Node.js. When running a bubble sort
on the server, up until 300 elements the performance was
similar, but after doubling the number to 600, Node.js and
HHVM were more than twice as fast as Zend. These
results are rather impressive for Node.js, but there is no
mention of versions or hardware specifications, so we
decided to try them on our implementations as well.
Our test system is made up of a quad core eight thread
Intel i7 8550u running at a maximum of 4Ghz with 16GB

DDR4 running at 2133Mhz, with the Windows 10
operating system running on a 256gb Sandisk X600 M.2
SSD.
Much to my suprise, upon running the request
benchmark, it reported 19.65 requests per second on
average for the Node.js implementation and a mere 3.22
requests per second for the PHP implementation. This
does not conclude that a Node.js server is more than 6
times faster than a PHP server, just that in our particular
implementations, Node.js is faster than PHP, perhaps also
aided by the NoSQL database.
When it comes to raw processing power, we also
attempted the bubble sort test, but we also added random
number generation to the test as well. The results are
presented in table 1 below.
TABLE 1. Bubble sort execution time with different number or
elements

300 elem 600 elem 1200 elem
Node.js 4.97ms 7.24ms 13.74ms
PHP 4.80ms 15.66ms 55.63ms

V. CONCLUSIONS

As we said before, it is pretty difficult to say at this point which
language is better for backend development. The choice
between the two will always have to be made with the whole
picture in mind and considering all the specific aspects of the
project itself.
If what you are looking for is a way to build a lightweight
system, easily extendable or even real time, than you should
choose Node.JS. It was proved to be a leading solution in the
world of REST apis of such characteristics and it connects easily
to non-relational databases due to the Javascript syntax it uses.
On the other hand, if you are looking for a complete solution,
on a project that has the potential to grow rather large, than PHP
is the answer. It is a robust solution, with a proven secure track
record that connects easily to any type of database, especially
SQL based ones.

REFERENCES

[1] Marty Matthews. 2014. PHP and MySQL Web
Development: A Beginner’s Guide (1st. ed.). McGraw-
Hill Education Group.
[2] en.wikipedia.org/wiki/Representational_state_tr
ansfer
[3] https://www.similartech.com/compare/nodejs-
vs-php
[4] https://en.wikipedia.org/wiki/PHP
[5] https://www.php.net/manual/en/intro-
whatis.php
[6] https://nodejs.org/en/about/
[7] https://medium.com/@abhi_/riseofnode-
60d8b17c8182
[8] https://en.wikipedia.org/wiki/Node.js
[9] http://expressjs.com/
[10] https://en.wikipedia.org/wiki/Express.js
[11] http://sinatrarb.com/
[12] https://webapplog.com/event-loop/
[13] https://dzone.com/articles/mean-stack-amp-
startups-are-they-made-for-each-oth
[14] https://www.ibm.com/cloud/learn/mean-stack-
explained
[15] https://dzone.com/articles/mean-stack-amp-
startups-are-they-made-for-each-oth
[16] https://deviq.com/reinventing-the-wheel/
[17] https://www.php.net/supported-versions.php
[18] https://nodejs.org/en/about/releases/
[19] https://www.hostingadvice.com/blog/comparin
g-node-js-vs-php-performance/