In this article, I’m going to explain Django REST Framework and, at the same time, compare it to ExpressJS (NodeJS Framework) and Laravel (PHP Framework).
PHP is most powerful full-stack web framework out there. It has an easy implementation, great community support (which only comes after a framework has proved it's worth), has a great guide to their implementation and its architecture makes it stand out. Laravel is already preloaded with things like sessions, cookies, caching management and are easily configured using their config files. With the help of its command-line tool artisan, Laravel makes development fast and keeps us unbothered from the trouble of maintaining a proper structure.
A framework that claims that you can develop your applications much faster using it and is truly acknowledged for that is Django. Django is Python's most popular web framework and a great option for your higher scalable applications ready to be deployed after running some checks on its setting.py file, which assures you of the security of your application. Fast development and great security are the two things Django provides.
Let's talk about Django REST. Well, Django REST is a more abstract version of Django solely abiding by the Representational State Transfer principle. Django REST has subclassed and modified the Django classes to provide the user with more layered and we will handle most of the things so you don't have to worry approach.
npm initcommand too.
.envfile, but it won't have built-in support for that. We have to use the
dotenvmodule to load our environmental variables.
package.jsonis the file that keeps track of packages (It's a JS thing).
We can generate a Laravel app using Laravel installer or composer. Both will give you the structure as shown below:
Modelsfolder is missing from its directory structure. In the next versions, it will come preloaded with
.envfile and files in the
configfolder to configure our application. In the
configfolder, we have multiple files, one each for the app, database, queues and so on, keeping each component's concern separate.
composer.jsonis there for us to keep track of PHP packages we have installed and you already know why
webpack.mix.jshelps us compile our CSS and JS files into a single bundle.
make:choose_functionalities_from_the_listed_oneswill create a separate directory if it does not exist before creating a file for your functionality.
django-admin startproject projectname. We will get the structure as follows: we have a one-parent directory and inside it, we have another directory that contains the files needed to boot our application.
manage.py startapp appName. These apps are nothing but directories containing specific functionality. The
startappcommand will give you a directory with the following structure.
init.pyfile that is generally empty. It signifies that the current directory is a Python package directory.
manage.pyfile contains the code to execute our commands. (
python manage.py command_you_want_execute)
setting.pyfile is the place where we configure our application. The use of an external module is required to load environment variables from the
.htmlfiles and are compiled using DTL(Django Template Engine) Or Jinja2(A popular alternative to DTL).
listenmethod on its app instance which in turn calls the Node.js raw implementation of creating a server and since Node.js under the hood uses the
httpmodule, your server is ready to serve HTTP requests.
Illuminate/Foundation/Applicationobject which requires the full path of your project's directory. Laravel at the time binds the interfaces with their component.
npmlibraries ready to contribute for validation.
Illuminate/Http/Request objects' validate method.
npmpackage that will utilize these storage units for you and will provide you some easy implementation and extra features.
get_responsemethod here calls the next middleware or the view in line.
process_view: Gets called just before executing view or middleware.
process_exception: When a view encounters an error, this hook gets called.
process_template_response: This hook is made specifically to run when the view uses the render method or returns a
setting.pyfile. Seems easy.
process_viewhook which is given
view_function(the view that's to be called) as an argument. A series of if conditions can be placed to check if we wanna apply this middleware here. Yeah, a little inconvenient.
startappcommand gives us a new directory with
Model.pyto store our model details, and a migration directory to store migrations that are generated from the command-line.
node-cronare the popular libraries that can help to schedule our cron jobs. Meanwhile, we have packages like bull and Kue for queues management in Express.js.
configfile. Laravel already has a built-in queue management service.
django_extensionwhich gives us a handful of command-line utilities to handle creating jobs, commands, show URLs, etc. Then, job scheduling can be done using the same approach as I mentioned for Laravel, but we are still one down with queue against Laravel even after using
Phew! You made it this far.
Laravel already wins in lots of scenarios in this article. It is loaded with the necessities that an application needs for a good head start and is easily configurable. Laravel's great documentation makes it easy for any developer to work with it.
Go with Django if you want your application to develop at a faster speed and are concerned about the security of your application. Sites like Pinterest, The Washington Post, Instagram are built using Django, so you can't question the scalability of Django. Its DRY principle is the reason Django is able to do so much with very few lines of code and doesn't get heavy as the application continues to grow.
Performance of each of this framework is excellent, so don't worry about that.
At the end You cannot judge a framework in an absolute sense. It all depends on your use case.
Thank you for reading!