Alternatives to Django REST framework logo

Alternatives to Django REST framework

Django, Flask, Tastypie, Swagger UI, and Graphene are the most popular alternatives and competitors to Django REST framework.
1K
889
+ 1
264

What is Django REST framework and what are its top alternatives?

It is a powerful and flexible toolkit that makes it easy to build Web APIs.
Django REST framework is a tool in the Microframeworks (Backend) category of a tech stack.
Django REST framework is an open source tool with 17K GitHub stars and 4.9K GitHub forks. Here’s a link to Django REST framework's open source repository on GitHub

Top Alternatives of Django REST framework

Django REST framework alternatives & related posts

Django logo

Django

11.5K
9.6K
3K
11.5K
9.6K
+ 1
3K
The Web framework for perfectionists with deadlines
Django logo
Django
VS
Django REST framework logo
Django REST framework

related Django posts

Dmitry Mukhin
Dmitry Mukhin
CTO at Uploadcare · | 24 upvotes · 586.1K views
atUploadcareUploadcare
Django
Django
Python
Python
React
React
Ember.js
Ember.js
Preact
Preact
PostCSS
PostCSS

Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.

Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.

For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.

However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.

All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.

See more
Django
Django
Flask
Flask

We initially though we would use Django because it seemed to have a lot of the things we needed out of the box. After a bit of research we realized that using Flask would be a better option since it is more flexible and would be lighter for our purposes. Having set up our REST api using Flask we believe that we did make the right decision. We found that the flexibility of Flask along with the many extensions available for it to be very appealing. We were able to add the functionality we needed without much difficulty thanks to the quality of the extensions and their documentation.

See more
Flask logo

Flask

6.4K
5.5K
1.2K
6.4K
5.5K
+ 1
1.2K
a microframework for Python based on Werkzeug, Jinja 2 and good intentions.
Flask logo
Flask
VS
Django REST framework logo
Django REST framework

related Flask posts

James Man
James Man
Software Engineer at Pinterest · | 29 upvotes · 196.6K views
Flask
Flask
React
React

One of our top priorities at Pinterest is fostering a safe and trustworthy experience for all Pinners. As Pinterest’s user base and ads business grow, the review volume has been increasing exponentially, and more content types require moderation support. To solve greater engineering and operational challenges at scale, we needed a highly-reliable and performant system to detect, report, evaluate, and act on abusive content and users and so we created Pinqueue.

Pinqueue-3.0 serves as a generic platform for content moderation and human labeling. Under the hood, Pinqueue3.0 is a Flask + React app powered by Pinterest’s very own Gestalt UI framework. On the backend, Pinqueue3.0 heavily relies on PinLater, a Pinterest-built reliable asynchronous job execution system, to handle the requests for enqueueing and action-taking. Using PinLater has significantly strengthened Pinqueue3.0’s overall infra with its capability of processing a massive load of events with configurable retry policies.

Hundreds of millions of people around the world use Pinterest to discover and do what they love, and our job is to protect them from abusive and harmful content. We’re committed to providing an inspirational yet safe experience to all Pinners. Solving trust & safety problems is a joint effort requiring expertise across multiple domains. Pinqueue3.0 not only plays a critical role in responsively taking down unsafe content, it also has become an enabler for future ML/automation initiatives by providing high-quality human labels. Going forward, we will continue to improve the review experience, measure review quality and collaborate with our machine learning teams to solve content moderation beyond manual reviews at an even larger scale.

See more
Django
Django
Flask
Flask

We initially though we would use Django because it seemed to have a lot of the things we needed out of the box. After a bit of research we realized that using Flask would be a better option since it is more flexible and would be lighter for our purposes. Having set up our REST api using Flask we believe that we did make the right decision. We found that the flexibility of Flask along with the many extensions available for it to be very appealing. We were able to add the functionality we needed without much difficulty thanks to the quality of the extensions and their documentation.

See more
Tastypie logo

Tastypie

31
32
4
31
32
+ 1
4
Creating delicious APIs for Django apps since 2010.
Tastypie logo
Tastypie
VS
Django REST framework logo
Django REST framework

related Swagger UI posts

Noah Zoschke
Noah Zoschke
Engineering Manager at Segment · | 29 upvotes · 753.4K views
atSegmentSegment
Postman
Postman
Markdown
Markdown
ReadMe.io
ReadMe.io
Swagger UI
Swagger UI
#Documentation
#Api
#QA

We just launched the Segment Config API (try it out for yourself here) — a set of public REST APIs that enable you to manage your Segment configuration. A public API is only as good as its #documentation. For the API reference doc we are using Postman.

Postman is an “API development environment”. You download the desktop app, and build API requests by URL and payload. Over time you can build up a set of requests and organize them into a “Postman Collection”. You can generalize a collection with “collection variables”. This allows you to parameterize things like username, password and workspace_name so a user can fill their own values in before making an API call. This makes it possible to use Postman for one-off API tasks instead of writing code.

Then you can add Markdown content to the entire collection, a folder of related methods, and/or every API method to explain how the APIs work. You can publish a collection and easily share it with a URL.

This turns Postman from a personal #API utility to full-blown public interactive API documentation. The result is a great looking web page with all the API calls, docs and sample requests and responses in one place. Check out the results here.

Postman’s powers don’t end here. You can automate Postman with “test scripts” and have it periodically run a collection scripts as “monitors”. We now have #QA around all the APIs in public docs to make sure they are always correct

Along the way we tried other techniques for documenting APIs like ReadMe.io or Swagger UI. These required a lot of effort to customize.

Writing and maintaining a Postman collection takes some work, but the resulting documentation site, interactivity and API testing tools are well worth it.

See more
Tim Nolet
Tim Nolet
Founder, Engineer & Dishwasher at Checkly · | 7 upvotes · 335.4K views
atChecklyHQChecklyHQ
JavaScript
JavaScript
Node.js
Node.js
hapi
hapi
Vue.js
Vue.js
Swagger UI
Swagger UI
Slate
Slate

JavaScript Node.js hapi Vue.js Swagger UI Slate

Two weeks ago we released the public API for Checkly. We already had an API that was serving our frontend Vue.js app. We decided to create an new set of API endpoints and not reuse the already existing one. The blog post linked below details what parts we needed to refactor, what parts we added and how we handled generating API documentation. More specifically, the post dives into:

  • Refactoring the existing Hapi.js based API
  • API key based authentication
  • Refactoring models with Objection.js
  • Validating plan limits
  • Generating Swagger & Slate based documentation
See more
Graphene logo

Graphene

59
70
0
59
70
+ 1
0
GraphQL framework for Python
Graphene logo
Graphene
VS
Django REST framework logo
Django REST framework

related Graphene posts

Malthe Jørgensen
Malthe Jørgensen
CTO at Peergrade · | 13 upvotes · 99.1K views
atPeergradePeergrade
PostgreSQL
PostgreSQL
Django
Django
GraphQL
GraphQL
Graphene
Graphene
Amazon RDS
Amazon RDS

We recently switched from MongoDB and the Python library MongoEngine to PostgreSQL and Django in order to:

  • Better leverage GraphQL (using the Graphene library)
  • Allow us to use the autogenerated Django admin interface
  • Allow better performance due to the way some of our pages present data
  • Give us more a mature stack in the form of Django replacing MongoEngine, which we had some issues with in the past.

MongoDB was hosted on mlab, and we now host Postgres on Amazon RDS .

See more
Michael Mota
Michael Mota
Founder at AlterEstate · | 6 upvotes · 28.3K views
atAlterEstateAlterEstate
Graphene
Graphene
Django
Django
GraphQL
GraphQL

We recently implemented GraphQL because we needed to build dynamic reports based on the user preference and configuration, this was extremely complicated with our actual RESTful API, the code started to get harder to maintain but switching to GraphQL helped us to to build beautiful reports for our clients that truly help them make data-driven decisions.

Our goal is to implemented GraphQL in the whole platform eventually, we are using Graphene , a python library for Django .

See more

related Spring Boot posts

Praveen Mooli
Praveen Mooli
Engineering Manager at Taylor and Francis · | 12 upvotes · 697.3K views
MongoDB Atlas
MongoDB Atlas
Java
Java
Spring Boot
Spring Boot
Node.js
Node.js
ExpressJS
ExpressJS
Python
Python
Flask
Flask
Amazon Kinesis
Amazon Kinesis
Amazon Kinesis Firehose
Amazon Kinesis Firehose
Amazon SNS
Amazon SNS
Amazon SQS
Amazon SQS
AWS Lambda
AWS Lambda
Angular 2
Angular 2
RxJS
RxJS
GitHub
GitHub
Travis CI
Travis CI
Terraform
Terraform
Docker
Docker
Serverless
Serverless
Amazon RDS
Amazon RDS
Amazon DynamoDB
Amazon DynamoDB
Amazon S3
Amazon S3
#Backend
#Microservices
#Eventsourcingframework
#Webapps
#Devops
#Data

We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

To build #Webapps we decided to use Angular 2 with RxJS

#Devops - GitHub , Travis CI , Terraform , Docker , Serverless

See more
Java
Java
JavaScript
JavaScript
Node.js
Node.js
nginx
nginx
Ubuntu
Ubuntu
MongoDB
MongoDB
Amazon EC2
Amazon EC2
Redis
Redis
Amazon S3
Amazon S3
AWS Lambda
AWS Lambda
RabbitMQ
RabbitMQ
Kafka
Kafka
MySQL
MySQL
Spring Boot
Spring Boot
Dropwizard
Dropwizard
Google Analytics
Google Analytics
Elasticsearch
Elasticsearch
Amazon Route 53
Amazon Route 53
GitHub
GitHub
Docker
Docker
Webpack
Webpack
CircleCI
CircleCI
Jenkins
Jenkins
Travis CI
Travis CI
Gradle
Gradle
Apache Maven
Apache Maven
Jira
Jira
notion.so
notion.so
Trello
Trello
Vue.js
Vue.js
Flutter
Flutter
Application & Data

Java JavaScript Node.js nginx Ubuntu MongoDB Amazon EC2 Redis Amazon S3 AWS Lambda RabbitMQ Kafka MySQL Spring Boot Dropwizard Vue.js Flutter

Utilities

Google Analytics Elasticsearch Amazon Route 53

DevOps

GitHub Docker Webpack CircleCI Jenkins Travis CI Gradle Apache Maven

Cooperation Tools

Jira notion.so Trello

See more

related Laravel posts

Antonio Sanchez
Antonio Sanchez
CEO at Kokoen GmbH · | 14 upvotes · 259.3K views
atKokoen GmbHKokoen GmbH
PHP
PHP
Laravel
Laravel
MySQL
MySQL
Go
Go
MongoDB
MongoDB
JavaScript
JavaScript
Node.js
Node.js
ExpressJS
ExpressJS

Back at the start of 2017, we decided to create a web-based tool for the SEO OnPage analysis of our clients' websites. We had over 2.000 websites to analyze, so we had to perform thousands of requests to get every single page from those websites, process the information and save the big amounts of data somewhere.

Very soon we realized that the initial chosen script language and database, PHP, Laravel and MySQL, was not going to be able to cope efficiently with such a task.

By that time, we were doing some experiments for other projects with a language we had recently get to know, Go , so we decided to get a try and code the crawler using it. It was fantastic, we could process much more data with way less CPU power and in less time. By using the concurrency abilites that the language has to offers, we could also do more Http requests in less time.

Unfortunately, I have no comparison numbers to show about the performance differences between Go and PHP since the difference was so clear from the beginning and that we didn't feel the need to do further comparison tests nor document it. We just switched fully to Go.

There was still a problem: despite the big amount of Data we were generating, MySQL was performing very well, but as we were adding more and more features to the software and with those features more and more different type of data to save, it was a nightmare for the database architects to structure everything correctly on the database, so it was clear what we had to do next: switch to a NoSQL database. So we switched to MongoDB, and it was also fantastic: we were expending almost zero time in thinking how to structure the Database and the performance also seemed to be better, but again, I have no comparison numbers to show due to the lack of time.

We also decided to switch the website from PHP and Laravel to JavaScript and Node.js and ExpressJS since working with the JSON Data that we were saving now in the Database would be easier.

As of now, we don't only use the tool intern but we also opened it for everyone to use for free: https://tool-seo.com

See more
Epistol
Epistol
Laravel
Laravel
PhpStorm
PhpStorm
Google Analytics
Google Analytics
Sass
Sass
HTML5
HTML5
JavaScript
JavaScript
Vue.js
Vue.js
Webpack
Webpack
Buddy
Buddy
nginx
nginx
Ubuntu
Ubuntu
GitHub
GitHub
Git
Git
Deployer
Deployer
CloudFlare
CloudFlare
Let's Encrypt
Let's Encrypt
Stripe
Stripe
Asana
Asana
Bulma
Bulma
PHP
PHP
#CDG
CDG

I use Laravel because it's the most advances PHP framework out there, easy to maintain, easy to upgrade and most of all : easy to get a handle on, and to follow every new technology ! PhpStorm is our main software to code, as of simplicity and full range of tools for a modern application.

Google Analytics Analytics of course for a tailored analytics, Bulma as an innovative CSS framework, coupled with our Sass (Scss) pre-processor.

As of more basic stuff, we use HTML5, JavaScript (but with Vue.js too) and Webpack to handle the generation of all this.

To deploy, we set up Buddy to easily send the updates on our nginx / Ubuntu server, where it will connect to our GitHub Git private repository, pull and do all the operations needed with Deployer .

CloudFlare ensure the rapidity of distribution of our content, and Let's Encrypt the https certificate that is more than necessary when we'll want to sell some products with our Stripe api calls.

Asana is here to let us list all the functionalities, possibilities and ideas we want to implement.

See more
Node.js logo

Node.js

46.7K
40.4K
8K
46.7K
40.4K
+ 1
8K
A platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications
Node.js logo
Node.js
VS
Django REST framework logo
Django REST framework

related Node.js posts

Nick Parsons
Nick Parsons
Director of Developer Marketing at Stream · | 34 upvotes · 674.5K views
atStreamStream
Stream
Stream
Go
Go
JavaScript
JavaScript
ES6
ES6
Node.js
Node.js
Babel
Babel
Yarn
Yarn
Python
Python
#FrameworksFullStack
#Languages

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages

See more
Nick Rockwell
Nick Rockwell
CTO at NY Times · | 30 upvotes · 885.1K views
atThe New York TimesThe New York Times
MySQL
MySQL
PHP
PHP
React
React
Apollo
Apollo
GraphQL
GraphQL
Node.js
Node.js
Kafka
Kafka
Apache HTTP Server
Apache HTTP Server

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more