Django builds on the idea of "reusable applications [1]": self-contained packages provide reusable features. You can assemble these reusable apps and build your own site with the specific code that applies to your site. Django has a rich ecosystem of reusable apps that you can use--pypi list over 8,000 Django apps [2]--But how do you know what's best?
To save you time, we've summed up five of the most favorite Django apps. They are:
- Cookiecutter[3]: The best way to build a Django website.
- Whitenoise[4]: The best static resource server.
- Django Rest Framework[5]: The best way to develop Rest APIs with Django.
- Wagtail[6]: Django-based best Content Management System (CMS).
- Django-allauth[7]: The best app for social account login (e.g. Twitter, Facebook, GitHub, etc.).
We also recommend that you look at the Django Packages[8], a directory of reusable Django apps. Django Packages organizes the Django application into a "table", where you can compare and make choices between different apps that are functionally similar. You can view the features and usage statistics provided in each package. (For example: this is the table for REST tools [9], which may help you understand why we recommend the Django REST Framework.)
Why should you believe us?
We use Django for almost any length of time. Before Django was released, two of Us (Frank and Jacob) worked in Lawrence Journal-world (the birthplace of Django) (infact, they both pushed the Django Open source release process). We have been running a consulting firm over the last eight years to advise companies how best to apply Django.
So we've witnessed the full history of the Django project and the community, and we've witnessed the rise and fall of those popular packages. Of the three of us, we personally may have tried more than half of the 8,000 apps, or we know who tried them. We have a deep understanding of how to make our applications solid and reliable, and we have a deep understanding of the sources that give these applications a lasting strength.
The best way to build a Django website: cookiecutter[All]
It's always a pain to build a new project or application. You can use Django built-in startproject
. However, if you are like us, you are more picky about how to do things. Cookiecutter solves this problem by providing you with a quick and easy way to build projects or easy-to-reuse application templates. A simple example: type pip install cookiecutter
, and then run the following command on the command line:
$ cookiecutter https://github.com/marcofucci/cookiecutter-simple-django
Next you need to answer a few simple questions, such as your project name, directory repo, author name, e-mail, and a few other minor questions about configuration. These will help you to add details about the project. We use the most primitive "foo" as our directory name. So Cokkiecutter built a simple Django project under the subdirectory "foo".
If you're wandering through the "Foo" project, you'll see that the other settings you just selected have been embedded in the file with the desired subdirectory, along with the required subdirectories. This "template" is defined in the Github warehouse URL that we just entered when we executed the cookiecutter
command. This sample project uses a Github remote repository as a template, but you can also use local templates, which is useful when building non-reusable projects.
We think Cookiecutter is a great Django package, but in fact it is very useful in the face of pure python and even non-Python related requirements. You can place all of your files in a repeatable, accurate position, making cookiecutter a great tool for simplifying (DRY) workflows.
The best static resource server: Whitenoise[]
Over the years, the static resources of hosting websites--Pictures, Javascript, css----are a very painful thing. The Django built-in Django.views.static.serve[13] view, as the Django article describes, is "unreliable in a production environment, so it should only provide accessibility to the development environment." "But using a" real "Web server, such as NGINX or a CDN to host media resources, can be difficult to configure.
Whitenoice solved the problem very briefly. It can set up static servers in a production environment as easily as in a development environment, and is hardened and optimized for production environments. The Setup method is extremely simple:
Make sure you're using Django's contrib.staticfiles[14] app and make sure you set the variable correctly in the config file STATIC_ROOT
.
To wsgi.py
enable Whitenoise in a file:
from django.core.wsgi import get_wsgi_applicationfrom whitenoise.django import DjangoWhiteNoiseapplication = get_wsgi_application()application = DjangoWhiteNoise(application)
Configuring it is really that simple! For large applications, you might want to use a dedicated media server and/or a CDN, but for most small or medium Django websites, Whitenoise is strong enough.
For more information on whitenoise, please check the documentation [15].
Best tools for developing REST APIs: Django rest Framework[+]
The REST API is rapidly becoming the standard feature of modern WEB applications. The API is simply to use JSON dialogs rather than HTML, and of course you can do that with Django. You can make your own view, set the appropriate one Content-Type
, and then return the JSON instead of the rendered HTML response. This is whatmost people do before the API framework is released like the Django Rest Framework [17] (hereinafter called DRF).
If you're familiar with Django's view classes, you'll think that using DRF to build the REST API is similar to using them, but DRF is only designed for specific API usage scenarios. The general API settings only require a little bit of code, so we don't offer a sample code that excites you, but rather highlights some of the more comfortable DRF features that can make you live:
- An auto-preview API can make your development and manual testing easy. You can view the sample code for DRF [18]. You can view the API response, and you don't need to do anything to support the Post/put/delete type of operation.
- Facilitates integration of various authentication methods, such as OAuth, Basic Auth, or API Tokens.
- Built request rate limit.
- API documents can be generated almost automatically when used in combination with Django-rest-swagger [19].
- Extensive third-party library ecosystem.
Of course, you can build the API without relying on DRF, but we can't imagine why you don't use DRF. Even if you don't use all of DRF's features, using a mature view library to build your own API will make your API more consistent, complete, and improve your development speed. If you haven't started using DRF, you should find some time to experience it.
The best cms:wagtail based on Django[+]
Wagtail is one of the most popular applications in the world of Django CMS (Content management systems), and its popularity has plenty of justification. Like most CMS, it has the flexibility to define different types of pages and their content through a simple Django model. With it, you can start from scratch in a few hours instead of days and build a basic manageable content management system. As a small example, defining an employee page type for your company's employees can be as simple as the following:
from wagtail.wagtailcore.models import Pagefrom wagtail.wagtailcore.fields Import richtextfieldfrom wagtail.wagtailadmin.edit_handlers import Fieldpanel, Multifieldpanelfrom Wagtail.wagtailimages.edit_handlers Import Imagechooserpanel class Staffpage (Page): name = models. Charfield (max_length=100) hire_date = models. Datefield () bio = models. Richtextfield () email = models. Emailfield () headshot = models. ForeignKey (' Wagtailimages. Image ', Null=true, blank=true) content_panels = Page.content_panels + [Fieldpanel (' Nam E '), Fieldpanel (' hire_date '), Fieldpanel (' email '), Fieldpanel (' bio ', classname= "full"), Imagechoosepanel (' headshot '), ]
However, Wagtail's real focus is on its flexibility and its easy-to-use, modern management page. You can control which areas of different types of pages are accessible, add complex additional logic to the page, and natively support standard adaptation/approval workflows. In most CMS systems, you will encounter difficulties at some point during development. While using Wagtail, we have made unremitting efforts to find a breakthrough, making it easy for us to develop a set of simple and stable system, so that the program completely according to our ideas to run. If you are interested in this, we have written an [in-depth understanding of wagtail][17.
The best tool for social account login: Django-allauth[+]
Django-allauth is a reusable Django application that solves your registration and certification needs. Whether you need to build a local registration system or a social account registration system, Django-allauth can help you do that.
This application supports a variety of authentication systems, such as username or email. Once the user has registered successfully, it can also provide a variety of account verification policies from authentication to email authentication. It also supports a variety of social and e-mail accounts. It also supports plug-in registration forms that allow users to answer additional questions when registering.
Django-allauth supports more than 20 certification providers, including Facebook, Github, Google and Twitter. If you find a social networking site that it does not support, it is possible to provide access support for the site through a third-party plugin. This project also supports custom backend, which can support custom authentication methods, which is great for everyone who has a custom certification requirement.
The Django-allauth is easy to configure and has a complete documentation [22]. The project has passed a lot of tests, so you can be confident that all of its parts will work.
Do you have a favorite Django bag? Please let us know in the comments.
Read the original
5 Favorite open-source Django packages