Why We Didn't Choose Node.js for the DreamFactory REST API Backend

our engineering team considered using node.js to build the dreamfactory rest api backend. there are some great things about node that we really like. developers can write javascript on both the client and the server, and the node package manager is great. but after a careful look, we decided that node was not the best choice. instead, we choose the laravel framework, the v8 engine, and php to write dreamfactory. this architecture offers some real advantages when it comes to building a rest api backend. read on, i think you will come to the same conclusion that we did.

node is great for some things...

node has an event-driven architecture capable of asynchronous input and output. this design optimizes throughput and scalability in web applications with many input and output operations. node has been used successfully for chat programs, browser games, and other applications that need real-time communications.

node is single threaded and has a single event loop. all of the javascript you write executes in this loop, and if a blocking operation happens in that code, then it will block the entire loop and nothing else will happen until it finishes. when you do something that takes time, like reading from a database, conducting an http transaction, or using the file system, then node makes an asynchronous call to that driver and continues on immediately.

when one of these long running operations is finished, node receives a callback. the callbacks are accomplished with a lightweight and highly efficient thread pool. in this manner, node is very good at waiting for things to happen, and doing this with a bare minimum of resources. other languages might have to spawn a thread or even start a new process in order to accomplish the same type of asynchronous operation.

one great application of node is the new lambda microservice from aws. the purpose of lambda is to simplify building smaller, on-demand applications that respond quickly to events and new information. lambda spends most of the time waiting for an event to happen, after which your snippet of javascript is run as a microservice. because of all the waiting involved, node is a good choice for this type of product.

another smart use of node is for an mqtt message broker. this software is used for internet of things (iot) applications where many devices need to communicate through a hub and spoke network. each device on the network might publish certain messages and subscribe to others. as you can imagine, most of the time this network is just waiting for a message to be published, so node also works well for an mqtt message broker.

... but not everything

if node is so nifty, then why don’t people use it to build websites? the answer is that websites follow a particular data access pattern. a request comes in, there are some database transactions, and a response goes out. the advantages of node start to fade away when there is a database transaction for every request and response. the problem is that the database driver needs to run in a separate process. this allows many people to use it at the same time. and so if you have to create a new process anyway, the fact that node can efficiently wait for an asynchronous database transaction to finish doesn’t help conserve resources or improve speed very much.

as it turns out, a rest api platform follows the same basic data access pattern that a simple website does. a request comes in, there is a database transaction, and the response goes out. on a website the transaction happens with html pages, and on a rest api backend the transaction happens with json documents, but the workflow is the same. so the advantages of node are mitigated when you are trying to build a rest api backend. in short, a rest api backend should be working all the time, not waiting for something to happen.

there is another problematic issue with node. if there is lots of heavy lifting to be done, either before or after the database transaction, then all of that work must be completed by a single thread running javascript. that might be fine for some applications, but if massive scalability is the goal, then this can become a bottleneck. two of the main uses cases for rest api services are widely distributed mobile applications and iot deployments. both of these scenarios could overwhelm a single cpu running node at scale.

a better way

so what is the best language for building a simple request and response website? the world’s most popular content management systems are drupal and wordpress, and they are both written in php. in fact, over 80% of the world’s websites are written in php, including facebook and yahoo. there is a long history of solving scalability problems with lamp stacks running php. web servers, load balancers, operating systems, databases, and the php language have been optimized for this basic request and response model.

some people might think that php is old hat. but take a look at the cutting edge laravel framework and the new performance enhancements in php 7.0. we have written elsewhere about the advantages of using modular laravel components for the dreamfactory platform . the popularity of php is another advantage, because third party database drivers are usually up to date and more widely tested than other languages. this was a key need for our rest api platform.

the diagram below shows the architecture for the dreamfactory backend. a process is assigned to the incoming request, the database or external service is called synchronously, and the response goes out on the same thread. if there is a lot of work to be done customizing, integrating, transforming or formatting the json request or response then this can happen in parallel without the single-threaded bottleneck. you need a separate process, but that was going to happen anyway because of the database transaction. for enhanced scalability we recommend running on nginx to reduce the overhead of handling multiple processes.

one thing we like about node is the ability to run javascript on the server. this capability appeals to javascript developers using client frameworks like angularjs and react . node is run on top of google’s v8 engine. so we also incorporated v8, but rather than running it in a single process like node, we run it in parallel for server-side scripting and customization. compare the blue boxes in the two architecture diagrams above to see the difference. we also support php, python, and node itself for scripting and customization, if you prefer.

there are many debates on the internet about how to scale node applications. vertical scaling seems possible, but horizontal scaling appears to be more difficult. in our case, we wanted to enable any system administrator to scale dreamfactory using techniques and technologies that they were already familiar with. because the platform is configured as a lamp stack, dreamfactory can be scaled vertically with additional processors or horizontally with a load balancer just like any website.

we adopted json web token (jwt) to ensure that the dreamfactory platform is completely stateless. need to double performance? double the number of instances. the only requirement is that all of your instances share the same default database and cache. dreamfactory does not need persistent local storage, and this enables our stack to run on paas systems like bluemix, openshift, heroku, and openstack, as well as docker management solutions like swarm, fleet, kubernetes, and mesos.

i have written this blog post to explore some of the technology and design decisions that we made along the way. since dreamfactory is a rest api backend, the platform could always be rewritten in another language if there were a compelling reason to do so. but as things stand, we are happy with the current architecture and scalability characteristics. reach out and let me know what you think about it .